No-named-argument variadic functions

No-named-argument variadic functions

[Joseph Myers]

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?

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

Re: No-named-argument variadic functions

[Richard Biener]

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

Re: No-named-argument variadic functions

[Joseph Myers]

On Thu, 20 Oct 2022, Richard Biener via Gcc wrote:

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

The issue with both of those options is that they don't seem very safe for 
code that accesses TYPE_ARG_TYPES directly, of which I think we have a 
lot.  Such code is quite likely to fall over on a TREE_LIST with a NULL 
type entry, and having code that encounters a (...) prototype treat it 
like an unprototyped function seems safer than having code that encounters 
an unprototyped function treat it like a (...) prototype because the code 
that created the function type failed to set a flag to say it's 
unprototyped.

(In principle TYPE_ARG_TYPES could change to have static type other than 
tree, with explicit flags both for stdarg_p and for prototype_p, which 
would provide GCC-build-time assurance that there's no non-updated code 
left that expects an old representation.  But that would be a very large 
change.)

-- 
Joseph S. Myers
joseph@codesourcery.com