On Thu, Sep 4, 2025 at 6:57 PM Joseph Myers <josmy...@redhat.com> wrote: > > On Wed, 3 Sep 2025, Alejandro Colomar wrote: > > > Hi Joseph, > > > > On Wed, Sep 03, 2025 at 03:44:28PM +0000, Joseph Myers wrote: > > > On Wed, 3 Sep 2025, Alejandro Colomar wrote: > > > > > > > Hi Joseph, > > > > > > > > I'd like to ping about this thread. > > > > > > As far as I know, nothing has been resolved about the semantics (and then > > > associated documentation and testcases) in the case of parameter forward > > > declarations where multiple declarations for a parameter are inconsistent > > > in whether it's declared as an array or a pointer, or in the array length > > > if declared as an array. In order to add this feature as a GNU extension, > > > we need defined, documented, tested semantics for how it interacts with > > > the other GNU extension of parameter forward declarations. > > > > I'd say what we need is to diagnose every case where this is tricky in > > forward declarations of arrays. Once we have the diagnostic, do you > > still want to define the behavior? Do we define behavior after a > > constraint violation? > > Constraint violation is one way to define things. If that's the desired > definition, of course it also needs to be implemented.
My suggestion to Alejandro is to implement https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3681.pdf (obviously excluding anything that would prevent existing programs using GCC's syntax from compiling). I might have done this myself if I had time, but I am busy with enhanced type variance and _Optional. From memory, my paper was brought onto the agenda of the recent WG14 meeting because Alejandro asked about the status of standardisation of parameter forward declarations. Since several people on WG14 want this feature to be standardised, someone should implement N3681 in Clang too, since one of their objections was that they do not have enough resources to implement C language features that are not useful in C++. (This particular feature is not useful because C++ does not support dependent types, so obviously they are going to resist it.) I do not know whether Alejandro has time to do this work, but it seems like the best way to determine whether Clang's objections have any real substance, and to prove that the feature is feasible and useful as specified in N3681. SDCC would also need an implementation, and providing one might remove their objections, if any. Christopher
