Macro names imbedded in pp-numbers [repost]

[Doug Gwyn]

In article <11134 at riks.csl.sony.co.jp>, diamond at csl.sony.co.jp (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.  This appears
- to match the committee's intention, is not optional, and is not
- implementation-defined.  Why?

The Rationale explains that.

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

No, since so far as I can tell you really have to implement a
tokenizing preprocessor anyway, the pp-number is a single preprocessing
token and thus will not match "getchar" naturally; no additional
kludgery is required to ensure this.

- We have recently had discussions of what-is-reasonable vs. what-is-
- written.  Does anyone think we can appeal to reason in this case,
- so that implementations might be allowed to expand macros that are
- found as independent real-tokens even though they're not separate
- preprocessor-tokens?

There ARE no "real-tokens" until translation phase 7.  Preprocessing
is REQUIRED to deal solely with preprocessing tokens.  I think that
general framework is fairly easy to defend on "reasonable" grounds.

You could of course complain that you don't want to have to implement
a tokenizing preprocessor, or that you don't want to have to wait
until translation phase 7 to convert pp-numbers to C numbers, or that
you just don't like the whole notion of pp-numbers.  Believe me,
X3J11 has heard all the arguments before..