Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!milton!ogicse!intelhf!ichips!inews!pima!bhoughto
From: bhoughto@pima.intel.com (Blair P. Houghton)
Newsgroups: comp.std.c
Subject: Re: The Preprocessor and tokens
Keywords: cpp
Message-ID: <3549@inews.intel.com>
Date: 29 Mar 91 06:41:56 GMT
Article-I.D.: inews.3549
References: <3137@wyse.wyse.com> <1991Mar27.033525.21697@tkou02.enet.dec.com> <3140@wyse.wyse.com>
Sender: news@inews.intel.com
Organization: Intel Corp, Chandler, AZ
Lines: 28

In article <3140@wyse.wyse.com> cmills@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."