Date: Wed, 12 Nov 2025 20:20:08 +0000
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
> }
>
> 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.
>
I thought part of the rationale for the C23 change was that no
implementation actually used the second argument anyway, so why would it
matter if they wrote va_start(list, i) here?
>
> >> 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
>
> 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.
>
I thought part of the rationale for the C23 change was that no
implementation actually used the second argument anyway, so why would it
matter if they wrote va_start(list, i) here?
>
> >> 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
>
Received on 2025-11-12 20:20:26
