🚀 go-pugleaf

In article <11134@riks.csl.sony.co.jp> diamond@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@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.)