Re: Possible variadic macro bug

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

Peter Seebach wrote:-

> Just a side question:
> 
> If the spec were some day revised to say that
> 	#define foo (a, ...) bar(a, __VA_ARGS__)
> 	foo(a)
> 	foo(b, c)
> produced
> 	bar(a)
> 	bar(b, c)
> would this be a big problem for gcc?  Essentially, this removes the ## before
> the comma, and is otherwise (so far as I can tell) equivalent to what you're
> doing.  We have draft wording floating around that would allow the ", ..." to
> be ommitted in calls to variadic macros.

I agree with Clive Feather's point that the use of ## is ugly because
it gives 2 meanings to ##; I said as much over a year ago when this
was discussed.  So I'm in favour of a clean replacement.  I didn't
like any of his three suggestions at all, though.

> The reason I ask is that a couple of people have objected to the ",
> ##" as being ugly (which I grudgingly grant that it is), and it
> seems to me that the above change cannot break any
> currently-conforming code, and always does what the user meant.  The
> formal wording would state that a comma preceeding __VA_ARGS__ is
> omitted if __VA_ARGS__ is empty.  I don't think anyone ever wants
> the comma in that case.

It might work.  I suspect it could, however, break some nested macro
expansions where the nesting macro was expecting an empty argument.
There are some really obscene uses of varargs macros floating around.
testsuite/gcc.dg/cpp/macro{3,8}.c and vararg{1,2}.c look like
candidates for something to go wrong.  [And if you want a truly mind-
boggling example of abuse of varargs macros, check out vararg2.c!].
But, at a glance, they seem like they would still be OK.

If GCC passed its existing testsuite without regresssions with this
modification, I'd be quite happy to make it permanent, as the existing
tests cover macro expansion very thoroughly.  We could then deprecate
the existing kludges.  I can't speak for Zack, though.

> When this gets written up, I'd like to present both alternatives, in
> the hopes of increasing the chance that *something* gets done.  I'd
> sort of prefer the existing GNU C solution in terms of prior art,
> but I don't really like the visual effect of ",##".

Agreed.

Neil.