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 wrote:
> 
> 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.
> 
> "paste(foo, bar)" is what cpp currently gives, correctly IMO.
> 
> Neil.

Okay, I see your point. Still, it's hard to accept that _all_ current
preprocessors (I've tried 6) have had the same bug since C89, that's
over 10 years. I think this should be discussed by WG14 -- I'm not a
member but if you (or someone who's reading this) is, I would encourage
you to raise this to see what the other implementers think.

We have code that relies on this working and I'd be willing to bet that
there will be other software as well that depends on the old behavior.

Regards
Martin

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