[Bug preprocessor/61613] New: ,##__VA_ARGS__ fails to expand the first variadic argument if it is a macro-name

["arthur.j.odwyer at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61613

            Bug ID: 61613
           Summary: ,##__VA_ARGS__ fails to expand the first variadic
                    argument if it is a macro-name
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: arthur.j.odwyer at gmail dot com

The following program uses the ",##__VA_ARGS__" token-pasting extension
described here: https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html

cat >test.cc <<EOF
#include <stdio.h>
const char* print(int, const char* s) { puts(s); return "result"; }
#define print(x,...) (print(1,"macro"),print(1, ##__VA_ARGS__))
int main() {
    print(1,print(1,"world"));
}
EOF
g++ test.cc
./a.out


This program prints "macro world result", indicating that the second (inner)
occurrence of `print` on line 5 was blue-painted before it was expanded.

If you remove the "##" from the definition of the `print` macro, the new
program prints "macro world result result", indicating that both occurrences of
`print` on line 5 have been expanded.

I believe that the latter behavior is correct and the former behavior is WRONG;
I cannot convince myself that the presence of ,## on line 3 should have any
effect.

I think maybe what's happening is that the preprocessor is **actually**
token-pasting `,` and `print` to get the pp-token `,print` which is not a
macro-name so it doesn't get expanded; but in that case, I would expect a
syntax error because `,print` is not a valid pp-token.  Silently blue-painting
the first token of every variadic macro argument list is a big misfeature.



This bug was discovered while testing an "on-scope-exit-do" macro:

    {
        OnScopeExitDo(baz());
        OnScopeExitDo(bar());
        foo();
    }

worked as expected, but

    {
        OnScopeExitDo(OnScopeExitDo(baz()); bar());
        foo();
    }

failed to compile, complaining that it couldn't find any function definition
for the inner, incorrectly-blue-painted `OnScopeExitDo`.  The bogus error
disappeared when I removed the ## from the macro's implementation.


Bug 9764 looks like the exact same issue, reported against GCC 2.95, confirmed,
and resolved as "fixed" in 2003. Well, the bug is back again!
Bug 56825 (filed against 4.7 and currently unconfirmed) also looks like a
possible duplicate.


Clang 3.4 and 3.5 have the same bug, possibly out of respect for GCC 4
compatibility. I'm reporting it to them as well, and will post the link here
when I have done it.