karl@haddock.ima.isc.com (Karl Heuer) (12/22/88)
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