MSVC doesn't expand __VA_ARGS__ correctly

Question

Consider this code:

#define F(x, ...) X = x and VA_ARGS = __VA_ARGS__ #define G(...) F(__VA_ARGS__) F(1, 2, 3) G(1, 2, 3)

The expected output is X = 1 and VA_ARGS = 2, 3 for both macros, and that's what I'm getting with GCC, however, MSVC expands this as:

X = 1 and VA_ARGS = 2, 3 X = 1, 2, 3 and VA_ARGS =

That is, __VA_ARGS__ is expanded as a single argument, instead of being broken down to multiple ones.

Any way around this?

Ise Wisteria · Accepted Answer · 2021-02-19 01:18:25Z

79

Edit: This issue might be resolved by using /Zc:preprocessor or /experimental:preprocessor option in recent MSVC. For the details, please see here.

MSVC's preprocessor seems to behave quite differently from the standard specification.
Probably the following workaround will help:

#define EXPAND( x ) x #define F(x, ...) X = x and VA_ARGS = __VA_ARGS__ #define G(...) EXPAND( F(__VA_ARGS__) )

edited Feb 19, 2021 at 1:18

answered Feb 27, 2011 at 17:24

Ise Wisteria

11.7k2 gold badges45 silver badges26 bronze badges

Sign up to request clarification or add additional context in comments.

9 Comments

bk1e Over a year ago

__VA_ARGS__ isn't part of standard C++ yet. Does the draft standard actually specify what the behavior should be in this case?

Ise Wisteria Over a year ago

@bk1e: Sorry, as I don't have the ability, I can't explain the preprocess in upcoming C++ standard in detail here, but it is unlikely to be quite different from C99.

Virus721 Over a year ago

Could someone please explain this ? Is "and VA_ARGS = VA_ARGS" a valid piece of C code or is it just a human readable text that is here as a comment ? if this is valid code, what is "and VA_ARGS = VA_ARGS" doing ? Thank you.

solstice333 Over a year ago

Oh I think I see...let's say that __VA_ARGS__ is 1, 2 instead for simplicity. EXPAND(x) x takes F(__VA_ARGS__)) and replaces it with literally F(1, 2) so that F(1, 2) gets processed instead of F(__VA_ARGS__) where __VA_ARGS__ is seen as a single entity if that makes sense...

hassec Over a year ago

@IseWisteria, @rbrich already mentioned it below that there is now the compiler switch /Zc:preprocessor see here which will unpack __VA_ARGS__ correctly. Maybe worth editing your answer to include this in addition to your original solution?

|

Cody Gray · Accepted Answer · 2015-06-01 11:44:20Z

I posted the following Microsoft support issue:

The following program gives compilation error because the precompiler expands __VA_ARGS__ incorrectly:
#include <stdio.h> #define A2(a1, a2) ((a1)+(a2)) #define A_VA(...) A2(__VA_ARGS__) int main(int argc, char *argv[]) { printf("%d\n", A_VA(1, 2)); return 0; } 
The preprocessor expands the printf to: printf("%d\n", ((1, 2)+()));

instead of printf("%d\n", ((1)+(2)));

I received the following unsatisfying answer from a Microsoft compiler team developer:

Hi: The Visual C++ compiler is behaving correctly in this case. If you combine the rule that tokens that match the '...' at the inital macro invocation are combined to form a single entity (16.3/p12) with the rule that sub-macros are expanded before argument replacement (16.3.1/p1) then in this case the compiler believes that A2 is invoked with a single argument: hence the error message.

Thanks for passing along MS's rationale. It seems they are interpreting "combined to form a single item" in 16.3.1/p12 as "combined to form a single, permanently indivisible preprocessor token", which would seem to be less useful. I'd expect the substituted tokens to be reseparated at least for the rescan step given in 16.3.4, which seems to be what other compilers are doing.
I strongly agree but I'm evidently spoiled by GCC and Clang. Can either of you think of a use case for the MSVC behavior, or is it just a matter of consistency for consistency's sake in spite of expressibility? I'm well out of my element, but "...In this case the compiler believes..." doesn't sound very convincing, let alone useful for anyone trying to write agnostic code. I have a few ideas for workarounds, but my Windows partition is out of commission. I'd like to see someone attempt it in any case. Sorry for the rant and/or necropost.
FWIW, here's another bug on the same issue, where the team admits it is an error but says it isn't high enough priority to fix (7 years ago).
There is now /experimental:preprocessor or /Zc:preprocessor compiler switch which makes the preprocessor behave correctly. It fixed the issue for me.

chys · Accepted Answer · 2011-09-18 06:28:13Z

What version of MSVC are you using? You will need Visual C++ 2010.

__VA_ARGS__ was first introduced by C99. MSVC never attempted to support C99, so the support was not added.

Now, however, __VA_ARGS__ is included in the new C++ standard, C++2011 (previously known as C++0x), which Microsoft apparently plans to support, so it has been supported in recent versions of MSVC.

BTW, you will need to use a .cpp suffix to your source file to get this support. MSVC hasn't updated its C frontend for a long time.

Collectives™ on Stack Overflow

MSVC doesn't expand __VA_ARGS__ correctly

3 Answers 3

9 Comments

4 Comments

Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

3 Answers 3

9 Comments

4 Comments

Comments

Linked

Related