On Thu, 3 Feb 2022 at 20:48, Jens Maurer via Liaison <
liaison_at_[hidden]> wrote:

> On 03/02/2022 13.36, Aaron Ballman via Liaison wrote:
> > I would like to add a paper to next week's agenda at the request of
> > WG14 (who are meeting this week for a plenary meeting).
> >
> > WG14 N2919 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2919.pdf)
> > Relax requirements for variadic parameter lists
> > This paper proposes allowing a function signature consisting solely of
> > an ellipsis in C (e.g., void foo(...);) and changes the va_start macro
> > so that its second argument is optional and never evaluated (only the
> > first parameter is used). The author is looking for feedback on
> > whether this proposal will cause compatibility concerns, as WG14 is
> > intending to add this feature to C23.
>
> The syntax "void foo(...)" is already supported in C++,
> so this part seems not an issue.
>
> It would be good to have an overview in the paper which (major)
> compilers already use some __builtin_va_start and which ones still
> look at parmN. If (the C modes of) all major C++ compilers already
> do the former without inspecting parmN, there doesn't seem to be an
> issue.
>

I agree that if it's OK for C, it's OK for C++ too.

The difficult part is being sure there are no obscure architectures where
it is still needed, but I don't see any in the GCC tree. It's possible
there are some custom ports of GCC making use of the target-specific hook
for expanding __builtin_va_start to whatever code is needed. I don't
*think* any of the architectures supported by the official GCC releases do
that though, if I'm reading the code correctly. GCC certainly "looks at"
the argument today, passing it to the target-specific hooks, but they don't
seem to actually use it.




> (C++ would need to adjust [cstdarg.syn] for the modified
> va_start definition.)
>