Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!brutus.cs.uiuc.edu!husc6!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.std.c
Subject: Re: Macro names imbedded in pp-numbers [repost]
Message-ID: <15224@haddock.ima.isc.com>
Date: 18 Nov 89 02:51:43 GMT
References: <11134@riks.csl.sony.co.jp> <15217@haddock.ima.isc.com> <1643@crdos1.crd.ge.COM>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 22

In article <1643@crdos1.crd.ge.COM> davidsen@crdos1 (bill davidsen) writes:
>	#define F_LIMIT	0x14e
>	top3 = triad(bset, F_LIMIT+3);
>The last is interesting, because if F_LIMIT+3 is taken as a float
>value, and if there is a prototype...

As Doug has already pointed out, this is not a problem because there is a
token delimiter folling F_LIMIT.  Besides, there are no hex-floats in ANSI C
(nor in any extension that I'm aware of); "0x14e+3" is a pp-token that cannot
be resolved into a real token.  (As is also, for example, "018" or "4s".)  If
the Committee had tried to make this a legal token, it would have been a Quiet
Change--and *that* would have been a lot more controversial!

>I'm really hoping that this could be treated as a wording change, not
>requiring a vote, but I suspect it is too big for that.

The guiding principle is that a change that reflects the Committee's original
intent is editorial, one that does not is substantive.  Unfortunately, this
behavior appeared as an explicit example in the Rationale, so it's hard to
argue that the Committee didn't intend it.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint