On Thu, 13 Nov 2025, 19:41 Aaron Ballman, <aaron_at_[hidden]> wrote:

> On Thu, Nov 13, 2025 at 2:00 PM Jonathan Wakely <cxx_at_[hidden]> wrote:
> >
> >
> >
> > On Thu, 13 Nov 2025 at 13:18, Aaron Ballman <aaron_at_[hidden]>
> wrote:
> >>
> >> Responding to two separate threads below.
> >>
> >> On Wed, Nov 12, 2025 at 3:02 PM Jonathan Wakely <cxx_at_[hidden]> wrote:
> >> > 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".
> >>
> >> Not really, no.
> >>
> >> The intent from WG14 (AIUI) was that we should continue to accept code
> >> that was correct in previous versions of C and start accepting only a
> >> single argument of va_list type, and nothing else. I think the C
> >> wording is close to capturing that intent, but it's not fully clear
> >> whether Clang is acting in a non-conforming manner here (in C) by
> >> rejecting this code which GCC accepts: https://godbolt.org/z/zq6jnqedM
> >> What I'm gathering from this discussion is that both Clang and GCC's
> >> behavior is conforming,
> >>
> >> I do not think the C++ wording matches the intent from C because it
> >> explicitly discards all tokens. I'd like to see the two standards
> >> agree on the behavior here, and I think the tokens should be expanded
> >> and not discarded because discarding the tokens leads to a specified
> >> behavior for code which I think should be ill-formed in C++;
> >> basically, I think Clang's behavior on the example above should apply
> >> in C++ but per the current wording, Clang is non-conforming. The
> >> changes LWG made in https://cplusplus.github.io/LWG/issue4388 don't
> >> quite accomplish what I was hoping for. The new words say "and any of
> >> the second or subsequent arguments expands to include" but the old
> >> words "The preprocessing tokens comprising the second and subsequent
> >> arguments to va_start (if any) are discarded." still remain.
> >
> >
> > That was very much intentional.
> >
> > The change is to say that certain misuses are ill-formed; no diagnostic
> required. There was no intention to also change it to not discard the
> tokens. We just don't want to imply that discarding the tokens means that
> it's somehow OK to use unmatched parentheses or completely invalid tokens
> there, and expect compilers to handle that somehow and make the program
> well-formed.
>
> Which is good, I think the changes that LWG made are correct and
> necessary, just insufficient for addressing a separate concern.
>
> >> So I read
> >> that as requiring us to expand __COUNTER__ which would increment it,
> >> but it also requires us to not reject code from my linked example
> >> because the resulting expanded tokens are discarded. I think it should
> >> say the (non-preprocessing) tokens are not evaluated.
> >
> >
> > I still find it extremely hard to care about anybody dumb enough to do
> *anything* in the second argument to va_start. We've already spent more
> time on these corner cases than any users will ever spend being confused or
> upset by this aspect of va_start.
>
> I get that you don't care. I don't get why you insist I don't care.
>

Because my working group has better things to spend time on, hundreds of
unresolved defects that caused more problems for users than this ever will.

This study group's bailiwick is to address needless incompatibilities
> between the languages, that's what I'm asking for.
>

I don't think this group (and then WG14 and LWG and then all of WG21)
should spend time on irrelevancies though. Some inconsistencies don't
matter.


> > If you warn about anything except an identifier as the second argument,
> is that good enough?
>
> No.
>
> va_start(list, this_identifier_does_not_exist) should not compile for
> the same reason that 1 || this_identifier_does_not_exist does not
> despite not evaluating the second operand in either case. The current
> C++ wording prevents an implementation from rejecting that code
> because of the normative requirement to *discard* the tokens for that
> second argument to va_start.
>

This is where we disagree then. I don't see why it should be ill-formed.
You can always give a warning ("warning: this might not compile as C17
because you used an invalid identifier, even though it's actually fine
because it isn't used anyway, even in C17").

If the second argument is not used and never has been, I don't think it
helps users to insist that they must use a valid identifier there.

"error: you put the wrong thing here for this thing which is completely
ignored, use a different thing which will still be ignored"

Is any declared identifier ok, or do you only want to accept the last named
parameter before the ellipsis? I hope you at least want to tell the user
exactly what they need to write there to get the code to compile.

"error: this will only compile if you use 'foo' as the second argument"



> Anyhow, if SG22 doesn't care about this incompatibility, that's fine.
> Parts of this discussion were useful enough for me to figure out what
> Clang will do.
>
> Thanks!
>
> ~Aaron
>