Macro names imbedded in pp-numbers [repost]

[David Adrien Tanguay]

In article <11134 at riks.csl.sony.co.jp> diamond at ws.sony.junet (Norman Diamond) writes:
>Sorry for the repost, but the original posting has not drawn any
>  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 "0x7e-getchar" is picked up as a pre-processor number and later converted
into a token. In section 3.1, under constraints, it says

	"Each preprocessing token that is converted into a token shall
	 have the lexical form of a keyword, an identifier, a constant,
	 a string literal, an operator, or a punctuator."

"0x7e-getchar" is none of these, so I think a diagnostic message must be
issued at that point. However, there might be a statement elsewhere
that says that a pre-processor token can be converted into a sequence
of tokens.

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

This problem was brought to the committee's attention, but it took them
a while to understand the problem (they thought everybody was complaining
about the concept of a pre-processor number, rather than the specific
definition). By the time they did figure it out, they had already declared
that the botched definition would stand. (Hopefully a committee member will
inject some reality into the previous sentence.) Oh well, you should be
using white space anyway.

David Tanguay