On 11/12/25 19:17, Aaron Ballman via Liaison wrote:
> 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.

Ok.

> 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.

> 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.
I was trying to tell you earlier that I don't believe C++ had any "intent"
of its own in that area, whatever the current wording outcome is.

But I do find the C23 wording unclear. It says

"Additional arguments beyond the first given to the va_start macro may be expanded and used
in unspecified contexts where they are unevaluated."

That's a normative permission ("may") in a "Recommended practice" paragraph.
That feels like a category error.

Can a user rely on macro-expanding the second and subsequent arguments?
But __COUNTER__ is certainly not a valid second argument (it does not
refer to a parameter), so this should be invalid anyway.

Jens