0x47e+barney not considered C

[tom at hcx2.SSD.HARRIS.COM]

I tried posting a comment about this before, but never got any
responses, so I suspect it became trapped in a maze of twisty little
passages in our local net without reaching the world at large.

To get your attention right away, I will point out the following
true fact:

      fred = 0x47e+barney ;

Is NOT a legal Ansii standard C statement. It contains a lexical
error.

Background:

Ansii C introduced the concept of pre-processing numbers, I quote
from the standard:

   Preprocessing numbers

   Syntax
           pp-number:
                   digit
                   . digit
                   pp-number digit
                   pp-number nondigit
                   pp-number e sign
                   pp-number E sign
                   pp-number .

   Description

   A preprocessing number begins with a digit optionally preceded by a
   period ( . ) and may be followed by letters, underscores, digits,
   periods, and e+ , e- , E+ , or E- character sequences.

   Preprocessing number tokens lexically include all floating and integer
   constant tokens.

   Semantics

   A preprocessing number does not have type or a value; it must be
   converted (as part of phase 7) to a floating constant token or an
   integer constant token to acquire both.

Prior to the introduction of pre-processing numbers (which, according
to the rationale, were introduced to `simplify' the definition of
tokens) I had always assumed that a pre-processing token consisted of
the longest valid prefix of a token according to the fairly
unambiguous definition at the front of the standard. I made this rash
assumption because it was sensible, easy to implement, well defined,
and only caused confusion when someone was doing something that was
just asking for trouble.

Apparently the C committee spent a lot of time looking at the last
case and decided that it was far more important to serve the needs of
the contestants in the annual obfuscated C contest than it was to
serve the needs of people who happen to have code in which a hex
constant ending in e is added to something. Thus, the origin of the
obscure and pointless `pre-processing number'.

I pointed out this error in a formal response to the standard, but the
committee was apparently too tired of arguing to do anything about it,
as a result, they decided to leave pre-processing numbers alone.

The best thing to do is get lots of complaints about this in to the
committee during this next review period. I am willing to put up with
pre-processing numbers, but they really need to be changed to separate
ones that lead off with 0x from the others.  I still like the longest
valid prefix rule much better, but I can live with anything that does
not turn perfectly valid C code into a lexical error.

If anyone out there can find some existing code that does this, that
would be excellent support for the need to fix this major flaw.

=====================================================================
    usenet: tahorsley at ssd.harris.com  USMail: Tom Horsley
compuserve: 76505,364                         511 Kingbird Circle
     genie: T.HORSLEY                         Delray Beach, FL  33444
====================== Astrology: Just say no! ======================