On Wed, Nov 12, 2025 at 12:39 PM Jonathan Wakely <cxx_at_[hidden]> wrote:
>
>
>
> On Wed, 12 Nov 2025, 15:52 Aaron Ballman via Liaison, <liaison_at_[hidden]> wrote:
>>
>> This is why I'm asking SG22 to step in; this seems like a needless incompatibility between C and C++.
>>
>> void func(int i, ...) {
>> va_list list;
>>
>> va_start(list, blah); // #1
>> va_start(list, __COUNTER__); // #2
>> }
>>
>> #1 is required to be diagnosed in C17 and C++23, is required to be accepted in C++26.
>
>
> Does it matter though?
>
> Are we really worried that people will start using va_start this way in C++26 and ... create code that can't be compiled as C++23? Who cares?
>
> Nobody wrote that code yesterday, because it didn't work. Why would anybody write that code today?

I picked examples that made the issues more obvious, but people are
fallible and you can run into this accidentally rather than
intentionally. e.g.,

void func(int i, int j, ...) {
  va_list list;
  va_start(list, i); // Oops, I meant j
}

So yes, I *am* worried people will start using va_start this way.
Specifically, I'm worried about people interested in trying out new
language modes locally but their code still has to compile in older
language modes on a build or test farm somewhere.

>> C23 is unclear IMO. The standard says the argument is not evaluated. So if the implementation expands to `sizeof(blah)` for some reason, that's allowed by the standard wording for va_start because `blah` is not evaluated? I think the intent for C23 is clear in that this code is expected to be semantically well-formed regardless of what it expands to, and there's a recommendation to diagnose if any additional arguments are passed.
>>
>> #2 is required to be diagnosed in C17 and C++23, is required to be accepted in C23 and C++26, where __COUNTER__ is expected to increment in C and expected to not increment in C++.
>
>
> Again, I find it hard to care.

I care because I want there to be one conforming implementation of
va_start in the <stdarg.h> header my compiler vends and the
differences between the standards make that annoying for no
discernible benefit to my users. If I'm going to go with one macro,
it's not clear which approach (if any) is closest to the intent from
either committee, which is why I'm asking SG22 to help resolve the
situation.

~Aaron