Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: The Preprocessor and tokens
Message-ID: <15606@smoke.brl.mil>
Date: 27 Mar 91 22:15:20 GMT
References: <3137@wyse.wyse.com> <1991Mar27.033525.21697@tkou02.enet.dec.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 28

In article <1991Mar27.033525.21697@tkou02.enet.dec.com> diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond) writes:
>>what does the Standard say about constuctions like these:
>>#define _	+ 42
>>int j = 6_;
>>#define N	42
>>int k = 0x7e+N;
>>Do K&R compilers do it any differently?
>Usually.  The standard broke some working, valid, code this time.

I've commented before about how sick I get of hearing people pontificate
over how "ANSI C breaks valid code".  In fact, the standard UNIX (Reiser)
preprocessor produces

	int j = 6_;

	int k = 0x7e+42;

for the example in question, which half does "what was wanted" and half
does NOT do "what was wanted".  It is this sort of inconsistent existing
practice that gave X3J11 the latitude to decide on the behavior specified
in the C standard.  Many alternative proposals were offered, including
several from members of the public during the public review process, but
ALL of them were technically flawed.  Given the difficulty of "getting it
right" during preprocessing, X3J11 opted to defer "getting it right" to a
later phase of translation.  Anyone using a decent coding style should
encounter no problems.  The only serious trap to watch out for is the
second example, which is avoidable by using whitespace around operators.
The first example is stupid anyway.