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 jos...@codesourcery.com
