ANSI C token set (including $ and @)

[Henry Spencer]

In article <9438 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>>That's what I thought, too.  But Karl pointed out to me that is
>>is possible to write a strictly conforming program that will NOT
>>be interpreted correctly by an implementation that allows '$' in
>>identifiers.
>
>No, it isn't.  Use of the $ character in an identifier produces
>"undefined behavior"...

Doug, can you cite chapter and verse for this?  Remember that preprocessor
tokens which are never converted to tokens are one of the exemptions from
the rule in 2.2.1.  After some study of the matter, I'm afraid my tentative
conclusion is that when a funny character disappears before pptoken->token
conversion time, the Oct draft is not entirely clear about whether its use
is undefined, implementation-defined, or neither.  In reality it must be
considered to be at least implementation-defined, since it may not even 
exist in the source character set on some weird system, but I cannot find
explicit words to that effect.  One would actually prefer that it be
undefined, but I doubt that you can do that without making it difficult
to have funny characters in sections of code that are #ifdefed out -- and
it is highly desirable that *that* be legitimate.

A.6.3.4 thinks that 2.2.1 says that any extra members of either character
set are implementation-defined, but those words are not found in 2.2.1.

I think the right approach would be to tighten the "preprocessor token"
exemption in 2.2.1 so that it refers only to the none-of-the-above
single-character preprocessor tokens, but it's too late.

In practice one can argue that the behavior is undefined under the
"anything not mentioned is undefined" rule in 1.6, but this is not really
entirely satisfactory.
-- 
Allegedly heard aboard Mir: "A |     Henry Spencer at U of Toronto Zoology
toast to comrade Van Allen!!"  | uunet!attcan!utzoo!henry henry at zoo.toronto.edu