https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33877
--- Comment #13 from Alejandro Colomar <foss+...@alejandro-colomar.es> ---
(In reply to Harald van Dijk from comment #12)
> (In reply to Alejandro Colomar from comment #8)
> > (In reply to Harald van Dijk from comment #7)
> > > If __VA_ARGC__ should return 0 here, then the behaviour of __VA_ARGC__
> > > needs
> > > to be documented very carefully to be different from the number of
> > > variable
> > > arguments supplied.
> >
> > Where is the specification of "the number of variable arguments supplied" so
> > that we can differ from it?
>
> It's never explicitly specified, in general foo() can be either 0 arguments
> or 1 empty argument, but prior to C23, the requirement that "there shall be
> more arguments in the invocation than there are parameters in the macro
> definition (excluding the ...)" (6.10.3) made it necessary to interpret it
> as 1 empty argument in your example.
I'll consider that the C Committee did that because they didn't have better
wording, and because they didn't even have a good idea of how variadic macros
should work. Just look at how badly __VA_OPT__ works with empty parameters,
and how they didn't even realize it's self-inconsistent. I think we need to
ignore everything the standard says about the number of arguments.
alx@debian:~/tmp$ cat v.c | nl -ba
1 #define bar(a, ...) __LINE__: bar: __VA_OPT__(,)__VA_ARGS__
2
3 bar(a)
4 bar(a,)
5 bar(a,b)
6 bar(a,b,)
7 bar(a,b,c)
8 bar(a,b,c,)
alx@debian:~/tmp$ gcc -E v.c | grep -v ^# | uniq
3: bar:
4: bar:
5: bar: ,b
6: bar: ,b,
7: bar: ,b,c
8: bar: ,b,c,
Anyone can justify how the committee thought line 4 makes any sense considering
lines 6 and 8? The standard wording about variadic macros never made any
sense, and contradicts GNU C's ## __VA_ARGS__. GCC was there first, and got
the semantics right, so let's stick to the GCC idea of counting arguments,
which is very clear. If ##__VA_ARGS__ removes the preceding comma, there are 0
arguments; if it doesn't, there's at least 1.
