On Wed, 12 Nov 2025 at 18:18, Aaron Ballman <aaron_at_[hidden]> wrote:

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

You could choose to warn here, because that would not have been correct in
C17. But you don't have to, you can just ignore it.

You could choose to warn for anything with side effects, including
preprocessor side effects like __COUNTER__. Point out to users that they're
doing something absurd.


>
> 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.
>
>
As I understand it, the whole point of the current specs is to allow
implementers to have freedom to provide helpful diagnostics if they choose
to. You seem to be saying "don't let me decide what helps my users, force
me to implement a particular behaviour".

That will probably result in worse diagnostics because requiring high
quality diagnostics is unlikely to happen, so we'll get some portable but
less helpful behaviour.