0x47e+barney not considered C

Jerry Schwarz jss at hector.UUCP
Fri Jul 1 02:01:49 AEST 1988


In article <120200001 at hcx2> tom at hcx2.UUCP writes:
>
>
>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.
>

Although I am not a member of the committee, I have seen many of
their working drafts and do not believe that there was ever any such
definition.  Nor do I believe it was ever the committee's intention.
Before the introduction of pp-numbers there was always a comment
about 1ex being an "illegal token" not two tokens. 

The rule you suggest is a bad one because it does not provide an an
easy way to extend the syntax of numbers.  For example, if I have an
implementation with a "long long" type  I might want to allow 6LL as
an integer constant of that type. Under the "longest legal prefix"
rule I can't. It gets tokenized as "6L" "L".  

>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'.
>

As the author of the comment (during the first public review period)
that proposed pp-numbers I resent the implication of the preceeding
paragraph. I anticipate an apology.

The earlier drafts were ambiguous about several lexical issues,
especially about the interactions between tokens and pp-tokens.   The
current proposal is not.  The main motivation was to clean up
issues surrounding things like the "1ex" question.  

I believe an explicit syntax for pp-numbers is required.  The "0xe+b"
example points to a flaw in the current definition. But, in my
opinion, it is a minor flaw and does not require a change at this
stage in the standardization process.

Jerry Schwarz
Bell Labs, Murray Hill



More information about the Comp.std.c mailing list