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

On Wed, Nov 12, 2025 at 4:12 PM Jens Maurer <jens.maurer_at_[hidden]> wrote:
> 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.

Sorry for missing that, that's good to know!

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

I also find the C wording unclear, beyond the category error. There's
no recommendation there; it just says "for example, an implementation
...". I think a plausible repair to C's wording would be to move
"additional arguments beyond the first" up to the Description section
so it's more clearly a normative permission, and "For example, an
implementation" should be reworded to something more along the lines
of "It is recommended that an implementation..." so it's clear that
there's a recommendation for producing a diagnostic.

~Aaron