0x47e+barney not considered C
Doug Gwyn
gwyn at brl-smoke.ARPA
Sat Jul 2 06:11:38 AEST 1988
In article <8194 at brl-smoke.ARPA>, gwyn at 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.
More information about the Comp.std.c
mailing list