I believe we discussed basically this same question within WG14 before adopting the wording, and the "evaluated" wording was a revision/compromise intended to reduce the structness of the `va_start` macro so that it could still report errors if they were needed, but not to require anything special of it above the behaviour that would be expected for any other macro that doesn't exand its arguments into an evaluated position.

So that second argument certainly isn't supposed to be being discarded by any special mechanism that would block incrementing `__COUNTER__` by some means not available to a user-defined macro. The original wording was stricter and might have implied this, but "evaluated" was chosen to indicate that it's the C-level evaluation that definitely doesn't happen, without implying anything about macro expansion. The macro part of this feature should just follow normal macro rules.

Thanks,

Alex

[Perforce Software]

Alex Celeste | Elder Witch of the C Compiler, Helix QAC<https://www.perforce.com/products/helix-qac>

Perforce Software<https://www.perforce.com>

P +1 612.517.2100

Visit Us On: LinkedIn<https://www.linkedin.com/company/perforce> | YouTube<https://www.youtube.com/user/perforcesoftware>

________________________________
From: Liaison <liaison-bounces_at_[hidden]> on behalf of J Decker via Liaison <liaison_at_[hidden]>
Sent: 11 November 2025 10:53
To: liaison_at_[hidden] <liaison_at_[hidden]>
Cc: J Decker <d3ck0r_at_[hidden]>
Subject: Re: [isocpp-wg14/wg21-liaison] Extra arguments to va_start



On Mon, Nov 10, 2025 at 9:10 AM Aaron Ballman via Liaison <liaison_at_[hidden]<mailto:liaison_at_[hidden]>> wrote:
I think the situation with va_start is a bit confused and there
appears to be implementation divergence in the wild. Consider this
code:

void func(int i, ...) {
  va_list list;
  va_start(list, +);
}

7.16.2.5p4: Only the first argument passed to va_start is evaluated.
If any additional arguments expand to include unbalanced parentheses,
or a preprocessing token that does not convert to a token, the
behavior is undefined.

'Is Evaluated' means 'computing the value of an expression and carrying out its associated side effects'
The second argument, not being evaluated, doesn't mean it's ignored, but that it's a literal that gets stuffed into the result without evaluation.

It doesn't say 'there's only one argument, and others are ignored' it says 'only the first is evaluated'

like doing `&((struct thing *)0)->member ` to get offsetof, the actual pointer there isn't evaluated...


So "list" is evaluated and "+" is not. Is the + then discarded as a
token? So is this valid? GCC and TCC accept, Clang and SDCC reject:
https://godbolt.org/z/Yf317Kxfx What if `+` was an undeclared
identifier instead?

(Keep in mind, we use the same "only ... is evaluated" in other
circumstances where the resulting code is still expected to be
semantically correct. e.g., `1 || undeclared_identifier` is still a
constraint violation even though `undeclared_identifier` is not
evaluated.)

Now think about this in terms of __COUNTER__ from C2y, with this code:

void func(int i, ...) {
  va_list list;
  va_start(list, __COUNTER__);
  static_assert(__COUNTER__ == 0);
}

Does that static assertion pass or fail? It fails in Clang and GCC,
doesn't compile correctly in SDCC, and TCC it succeeds:
https://godbolt.org/z/56qT9sarK At least with Clang and GCC, the
implementation of the macro is to forward to a builtin function so
that the builtin can generate appropriate diagnostics, so the
__COUNTER__ macro is expanded. Avoiding that expansion but keeping the
same level of QoI is a surprisingly large burden (we'd need a new
builtin and way to count the number of arguments in __VA_ARGS__ which
does not expand the tokens, I believe).

I think this is an issue SG22 should take up (hence, I've CCed Nina)
because the C++ wording is different from the C wording. In C++, the
tokens (if any) are *discarded* explicitly
(https://eel.is/c++draft/cstdarg.syn#1.2). I believe in C++, both of
those examples are expected to compile without diagnostics.

Thanks!

~Aaron
_______________________________________________
Liaison mailing list
Liaison_at_[hidden]p.org<mailto:Liaison_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
Searchable archives: http://lists.isocpp.org/liaison/2025/11/index.php



CAUTION: This email originated from outside of the organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe.


This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately.