🚀 go-pugleaf

In article <120@microsoft.UUCP> w-colinp@microsoft.UUCP (Colin Plumb) writes:
>For an example of an extension that is okay with __STDC__=1, try:
>
>anything using @ or $ (since they're not part of the C character set)

That's what I thought, too, until I noticed that 3.1.7 in the May88 dpANS
contains an example wherein @ and $ are scanned as separate preprocessing
tokens.  The accompanying text does not mention whether or not this behavior
is required of a conforming implementation.

Note that it is not sufficient to say that this can be handled by the
implementation-defined pasting of preprocessing tokens into tokens.  I can
construct a program that depends on this behavior, but does not use the
questionable characters beyond the preprocessing phase:
	#include <stdio.h>
	#define foo$_bar
	#if defined(foo)
	main() { printf("no\n"); return 0; }
	#else
	main() { printf("yes\n"); return 0; }
	#endif
Is a conforming implementation required to compile this to "no" (as suggested
by the dpANS example), or can it compile to "yes" (as is common practice in
VMS, Apollo, and the 4.3BSD compiler)?  (Such behavior is listed as a Common
Extension, but that appendix does not state which CE's are conforming.)

So, has any of this been changed in the latest Draft?  If not, do we have an
expert opinion on whether the Committee intended this to be optional?  (I
suspect the answer is "yes", at least among those members of the Committee
representing DEC and Apollo!)

(This also has implications for international implementations that want to
allow accented letters in identifiers.)

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint