Re: No-named-argument variadic functions

[Joseph Myers <joseph@codesourcery.com>]

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