Re: No-named-argument variadic functions

[Richard Biener <richard.guenther@gmail.com>]

On Thu, Oct 20, 2022 at 1:54 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> C2x allows variable-argument functions declared with (...) as parameters -
> no named arguments - as in C++.  It *also* allows such functions to access
> their parameters, unlike C++, by relaxing the requirements on va_start so
> it no longer needs to be passed the name of the last named parameter.
>
> My assumption is that such functions should thus use the ABI for
> variable-argument functions, to the extent that's different from that for
> other functions.  The main implementation issue I see is that GCC's
> internal representation for function types can't actually distinguish the
> (...) type from an unprototyped function - C++ functions with (...)
> arguments are treated by the middle end and back ends as unprototyped.
> (This probably works sufficiently well in ABI terms when the function
> can't actually use its arguments.  Back ends may well call what they think
> are unprototyped functions in a way compatible with variadic callees
> anyway, for compatibility with pre-standard C code that calls e.g. printf
> without a prototype, even though standard C has never allowed calling
> variable-argument functions without a prototype.)
>
> So there are a few questions here for implementing this C2x feature:
>
> 1. How should (...) be represented differently from unprototyped functions
> so that stdarg_p and prototype_p handle it properly?  Should I add a new
> language-independent type flag (there are plenty spare) to use for this?

I'd say unprototyped should stay with a NULL TYPE_ARG_TYPES but
a varargs function might change to have a TREE_LIST with a NULL type
as the trailing element?  Not sure if we want to change this also for
varargs functions with actual arguments.

If we want to go down the route with a flag on the function type then
I'd rather flag the unprototyped case and leave varargs without any
actual arguments as NULL TYPE_ARG_TYPES?

> 2. Does anyone see any likely ABI or back end issues from allowing
> single-argument calls to __builtin_va_start to access the arguments to
> such a function?  (I'd propose to redefine va_start in stdarg.h to use a
> single-argument call, discarding any subsequent arguments, only for C2x.)
>
> 3. Should the C++ front end be changed to mark (...) functions in whatever
> way is chosen for question 1 above, so that they start using the
> appropriate ABI (and, in particular, calls between C and C++, where a C
> implementation of such a function might use the arguments, work properly)?
> Or would there be problems with compatibility with existing callers or
> callees assuming the unprototyped function ABI?
>
> --
> Joseph S. Myers
> joseph@codesourcery.com