0x47e+barney not considered C
tom at hcx2.SSD.HARRIS.COM
tom at hcx2.SSD.HARRIS.COM
Wed Jun 29 21:58:00 AEST 1988
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! ======================
More information about the Comp.std.c
mailing list