Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!milton!ogicse!intelhf!ichips!iwarp.intel.com!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: <3434@inews.intel.com>
Date: 25 Mar 91 06:33:50 GMT
References: <3137@wyse.wyse.com>
Sender: news@inews.intel.com
Organization: Intel Corp, Chandler, AZ
Lines: 41

In article <3137@wyse.wyse.com> cmills@wyse.wyse.com () writes:
>Whilst composing this year's entry for the IOCCC, I stumbled on some
>ANSI wierdness and I was wondering, what does the Standard say about
>constuctions like these:
>
>#define _	+ 42
>
>int j = 6_;
>
>#define N	42
>
>int k = 0x7e+N;

The standard calls these things (`6_' and `0x7e+N')
"preprocessing numbers" and says they don't have to
be tokenized any further than that.

>My compiler refuses to exapnd the macros in these cases.

As it should; the macros aren't invoked.

>Is there a good
>reason for this (other than the preprocessor is a little easier to write
>if you define [0-9][0-9a-zA-Z_]* as a token)?

You forgot [+-.], which can also appear anywhere
after the leading digit.

Nope.  The rationale says the committee punted, claiming
that they didn't want to "burden" the preprocessor (uh, yeah...).

The last sentence of the paragraph in the rationale is,
"[in this case,] exercise of reasonable precaution in coding
style avoids surprises."

You can't BUY irony like that.

				--Blair
				  "If you think the IOCCC is a
				   mess, try reading X3.159-1989,
				   sometime..."