On Thu, Aug 31, 2017 at 09:54:33PM +0100, Al Viro wrote: > What a mess... Note that for non-vararg it *is* the right interpretation > (with #define A(x) [x] we will have A() interpreted as "empty token sequence > as the only argument", not "no arguments given"). For vararg case we > normally do not need to distinguish "not given" and "empty" - the only > thing that cares is exactly the ,## kludge. There with > #define B(x,...) [x,##__VA_ARGS__] > B(1) and B(1,) yield [1] and [1,] resp. And for everything other than > "just ..." we even get it right... > > I see what's going on there; will post a fix in a few. Fix macro argument parsing for (...) case Nasty corner case for the sake of ,##__VA_ARGS__ perversion - for something like #define A(x,...) [x,##__VA_ARGS] we want A(1) to expand to [1] and A(1,) - to [1,]. In other words, "no vararg given" and "vararg empty" are different and need to be distinguished. Unfortunately, in case when there was nothing but vararg we got it wrong - #define A(...) ,##__VA_ARGS ended up with A() interpreted as "one empty argument" (as it would in non-vararg case) rather than "zero arguments". Reported-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christopher Li <sparse@chrisli.org>