This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Preprocessor bug


Neil Booth <neilb@earthling.net> writes:

> Martin Sebor wrote:-
> 
> > Yes, although I don't agree that the two examples exploit the same
> > feature. You're talking about 6.10.3.4, p2, which is not relevant in
> > John's example. Here's a simplified testcase which I'm pretty sure is
> > well-formed and should produce, (what else?), foobar:
> 
> I don't agree.
> 
> > #define __paste(a,b)      a##b
> > #define paste(a,b)        __paste(a, b)
> > 
> > #define declfoo(a)        paste(foo, a)
> > #define declare(a, b)     paste(decl, a)(b)
> > 
> > declare(foo, bar)
> 
> declare(foo, bar)
>   paste(decl, foo)(bar)
>     declfoo(bar)
>       paste(foo, bar)  [*]
> 
> Again, it's a nested expansion, so the nested one doesn't expand.  You
> can only traverse each stage to get to [*] by rescanning the result of
> the previous macro expansion for new macros to expand, and rescanning
> is not permitted to expand already-expanded macros.  The standard is
> pretty clear about this.

BTW, this wording has not changed since C89.  It says:

  Further, if any nested replacements encounter the name of the macro
  being replaced, it is not replaced.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]