The Preprocessor and tokens

[Blair P. Houghton]

In article <3140 at wyse.wyse.com> cmills at wyse.UUCP (Chris Mills x2427 dept203) writes:
>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?

I like it.  Way-cool obfuscation.

>W's... (I suppose allowing all alphabetics was slightly less confusing than
>allowing only [ulfeULFE]).

The problem is that by the time the tokenizer sees the 'N'
it has already stuffed the `0x73+' into a PP_NUMBER
token-bin, and it's too late to ungetc() that much stuff
(only one char at a time, please).  This is a really lame
excuse for this non-parsing, if it's the real excuse.

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

Two tokens, and yes, if Q isn't L.  Two strings
concatenated lexically will be concatenated as data; i.e.
"hello,""world" becomes "hello,world".

It's only `preprocessing numbers' that are broken.

				--Blair
				  "Otherwise, I'd have bought it."