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