This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Possible cpp bug
- To: bug-gcc at gnu dot org
- Subject: Possible cpp bug
- From: David Holland <dholland at hcs dot harvard dot edu>
- Date: Sun, 2 Apr 2000 13:09:43 -0400 (EDT)
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