Macro names imbedded in pp-numbers [repost]

[Karl Heuer]

In article <11134 at riks.csl.sony.co.jp> diamond at ws.sony.junet (Norman Diamond) writes:
>Both the standard and the rationale say that in the pp-number
>  0x7e-getchar()
>it is illegal for my preprocessor to expand the getchar() macro.
>If there is a real getchar() function, it is guaranteed that the
>real function must be invoked by this expression.

"0x7e-getchar" scans as a single pp-number.  It fails to convert into a token
when it hits translation phase 7, and hence the program containing it is not
strictly conforming.

We are now in the realm of undefined behavior.  An ANSI-conforming compiler is
required to issue a diagnostic, but is then permitted to guess what the user
meant and continue processing the program.  In particular, it should be legal
for it to consider "getchar" for macro replacement.

>I will have to add code to my scanner, and slow it down, so that
>it will not call the preprocessor if it finds a macro in the middle
>of a pp-number.

Why should it "find" a macro in the middle of a pp-number, any more than it
should try to expand the substring "getc" in the token "fgetc"?

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint
(For those readers who don't know why "0x7e-getchar" is a single pp-token: The
Committee defined a single pattern to cover all variants of numeric constants,
including floating-point with exponents as well as hex integers.  They chose
to accept the resulting wart (that hex constants ending with "e" must not be
immediately followed by a sign) rather than rewrite the pattern to fix it.
Yes, I think this was a mistake.  No, it can't be changed.)