Path: utzoo!attcan!uunet!husc6!ukma!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.std.c
Subject: Re: 0x47e+barney not considered C
Message-ID: <8208@brl-smoke.ARPA>
Date: 1 Jul 88 20:11:38 GMT
References: <120200001@hcx2> <8194@brl-smoke.ARPA>
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 26

In article <8194@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> Is it that "0x47e" is supposed to be split into preprocessing tokens
> "0" and "x47e" ...

Oops, Dave Prosser straightened me out on this.  When I looked at the
pp-number grammar in section 3.1.8, somehow the construction
	pp-number:	pp-number nondigit
did not register.  Perhaps my eyes saw it but my mind refused to
believe what I saw.

Anyway, the problem is that the pp-number syntax is TOO greedy, not
(as I feared) that it was insufficiently broad.

Although it is somewhat annoying to realize that
	123zzz456
is a single valid preprocessing token, that wouldn't really matter
so long as it became invalid in translation phase 7, as in fact it does.
The truly serious problem is that
	0x47e+barney
or even
	0xE+0x10
appears to be invalid C because of this error in specification; it's
turned into a single token in phase 7 instead of the three tokens one
might expect.  I don't know a simple way to fix this (which certainly
was unintended), but probably other X3J11 committee members can figure
out how.  This does deserve a re-response and committee reconsideration.