Path: utzoo!yunexus!ists!jarvis.csri.toronto.edu!mailrus!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Macro names imbedded in pp-numbers [repost]
Message-ID: <11641@smoke.BRL.MIL>
Date: 17 Nov 89 22:57:44 GMT
Article-I.D.: smoke.11641
References: <11134@riks.csl.sony.co.jp> <15217@haddock.ima.isc.com> <1643@crdos1.crd.ge.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 18

In article <1643@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes:
>Example, for those not following this:
>	#define F_LIMIT	0x14e
>	/* and later in the program */
>	long error_count[F_LIMIT+5];	/* room for quadrant totals */
>	/* and also */
>	top3 = triad(bset, F_LIMIT+3);

There is no problem here, because the result of macro substitution is
not retokenized.

I don't feel like recounting the entire history of pp-numbers, even if
I could remember it all, but it was a reasonable solution to a very
difficult technical problem.  Earlier drafts tried to do it the way
you and Norman seem to think is "right", and it got more and more
snarled as we tried to get it untangled.  pp-numbers work well for the
intended purpose and cause problems only in very rare circumstances
and only for programmers with an obsessive aversion to white space.