Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mailrus!ames!haven!umd5!adm!smoke!gwyn
From: gwyn@smoke.ARPA (Doug Gwyn )
Newsgroups: comp.std.c
Subject: Re: Preprocessing issues
Message-ID: <8366@smoke.ARPA>
Date: 20 Aug 88 20:21:00 GMT
References: <64919@sun.uucp> <8358@smoke.ARPA> <6280@haddock.ima.isc.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 26

In article <6280@haddock.ima.isc.com> karl@haddock.isc.com (Karl Heuer) writes:
>How about the problem with preprocessing numbers, which seems to break the
>perfectly valid expression "0xe+N"?  Which alternative is the Committee likely
>to take:
>[a] Fix it, call it a substantive change, and go through another round.
>[b] Fix it, but call it an editorial change.
>[c] Leave it alone, and expect implementors to ignore the letter of the
>    Standard in favor of doing what is obviously the right thing.
>[d] Leave it alone, and expect users to not write such expressions.
>[e] Other ?

[c] is out, because we really do intend for conforming implementations to
comply with the specifications.

[b] seems most likely, assuming nobody at the meeting claims that they
really thought the intent was to disallow such expressions.  We usually
consider fixing a failure of the wording to properly express the
committee's intent as "editorial" unless a member objects.

>...  This would seem to preclude
>Common Extension A.6.5.2 in a conforming implementation.

I don't think it is promised anywhere that "common extensions" can
be accomplished in a conforming implementation.  In fact most of
them don't seem possible.  I've never wanted this section in the
Standard..