Possible cpp bug
David Holland
dholland@hcs.harvard.edu
Sun Apr 2 10:09:00 GMT 2000
Section 6.10.3.4 of the C99 draft I have here says
[#2] If the name of the macro being replaced is found during this
scan of the replacement list (not including the rest of the source
file's preprocessing tokens), it is not replaced. Further, if any
nested replacements encounter the name of the macro being replaced,
it is not replaced. These nonreplaced macro name preprocessing tokens
are no longer available for further replacement even if they are
later (re)examined in contexts in which that macro name preprocessing
token would otherwise have been replaced.
This is not exactly crystal clear, but I believe it affects the
following case: gcc's cpp emits "HACK HACK KLUDGE", and I think it
should only emit "HACK KLUDGE". However, I may be wrong; if so, please
advise.
This behavior was observed in both
Reading specs from /usr/local/lib/gcc-lib/alpha-dec-osf4.0d/2.8.1/specs
gcc version 2.8.1
and
Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/2.95.1/specs
gcc version 2.95.1 19990816 (release)
--- cut here: bug.c ---
#define KLUDGE HACK KLUDGE
#define concat(a,b) a ## b
#define callconcat(a,b) concat(a,b)
callconcat(KLUDGE, )
--- cut ---
--
- David A. Holland
dholland@hcs.harvard.edu
More information about the Gcc-bugs
mailing list