The Preprocessor and tokens

[Chris Mills x2427 dept203]

In article <1991Mar27.033525.21697 at tkou02.enet.dec.com> diamond at jit345.enet@tkou02.enet.dec.com (Norman Diamond) writes:
>In article <3137 at wyse.wyse.com> cmills at wyse.wyse.com () writes:
>
>>what does the Standard say about constuctions like these:
>>#define _	+ 42
>>int j = 6_;
>>#define N	42
>>int k = 0x7e+N;
>
>The standard forbids those macros from being expanded.
>However, since your program violates the ANSI syntax, the processor may do
>whatever it wishes, as long as it produces at least one diagnostic.  It
>could, if it wishes, give a warning and then do what you asked for.

What do you mean the preprocessor can do whatever it wants?  If the standard
forbids the expansions of the macros, then it can't do what I want, right?
Actually, since I'm deliberately trying to be obfuscated, I'd like

#include <stdio.h>
int N;
#define N 3
void main(argc, argv) char **argv; { printf("%d\n", 0x7e+N); }

to print 254 instead of 257 consistantly.  What, exactly is being violated
in this example that allows the preprocessor to be unpredictable?  As my
newfound understanding goes, the preproc. will see "0x73+N" as one token
and will not expand "N", and the compiler will see it as three, right?

>RTFS.

Love to.  Can't justify the cost of TFS for the occasional oddity like this.
Did manage to borrow a copy of K&RII, but could not find any reference to
the preprocessor being given license to think that numbers can contain
W's... (I suppose allowing all alphabetics was slightly less confusing than
allowing only [ulfeULFE]).

By the way, does L"string" work the same way?  Does the preproc. see this as
one token, or two, and is Q"string" also a preproc token?  Does anybody
actually use these things?

>--
>Norman Diamond       diamond at tkov50.enet.dec.com
>If this were the company's opinion, I wouldn't be allowed to post it.

				Chris Mills