Hi Chris, On Fri, Sep 05, 2025 at 11:15:26AM +0100, Christopher Bazley wrote: > 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 have some doubts about the proposal:
alx@debian:~/tmp$ cat fwd.c | nl
1 void f(int n, int n; int n);
2 void g(int n; int n; int n);
3 void h(int n, int m; int n, int m);
4 void i(int n; int m; int n, int m);
alx@debian:~/tmp$ gcc -S -Wall -Wextra fwd.c
fwd.c:1:19: error: redefinition of parameter ‘n’
1 | void f(int n, int n; int n);
| ~~~~^
fwd.c:1:12: note: previous definition of ‘n’ with type ‘int’
1 | void f(int n, int n; int n);
| ~~~~^
fwd.c:1:12: error: parameter ‘n’ has just a forward declaration
alx@debian:~/tmp$ gcc -S -Wall -Wextra -Wpedantic fwd.c
fwd.c:1:19: error: redefinition of parameter ‘n’
1 | void f(int n, int n; int n);
| ~~~~^
fwd.c:1:12: note: previous definition of ‘n’ with type ‘int’
1 | void f(int n, int n; int n);
| ~~~~^
fwd.c:1:1: warning: ISO C forbids forward parameter declarations
[-Wpedantic]
1 | void f(int n, int n; int n);
| ^~~~
fwd.c:1:12: error: parameter ‘n’ has just a forward declaration
1 | void f(int n, int n; int n);
| ~~~~^
fwd.c:2:1: warning: ISO C forbids forward parameter declarations
[-Wpedantic]
2 | void g(int n; int n; int n);
| ^~~~
fwd.c:3:1: warning: ISO C forbids forward parameter declarations
[-Wpedantic]
3 | void h(int n, int m; int n, int m);
| ^~~~
fwd.c:4:1: warning: ISO C forbids forward parameter declarations
[-Wpedantic]
4 | void i(int n; int m; int n, int m);
| ^~~~
- We want to keep the error in line 1, right?
- The diagnostic in lines 2 & 4 should be reworded, and enabled by -Wextra.
- I should remove the diagnostic in line 3, at least for >C23.
Right? I can do that.
> 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.
Yup.
> Since several people on WG14 want this feature to be standardised,
> someone should implement N3681 in Clang too,
I can try to make some time for that. I'm a bit busy with implementing
streq() in glibc, and a few other things, but could find free time for
this. My main blocker is C++, not time. It is very painful for me to
write anything in Clang because of the language it's written in.
> 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.
I have time; and Aaron would probably help me with doubts if I try.
I just need energy to resist the pain of reading and writing C++ code.
> SDCC would also need an implementation, and providing one might remove
> their objections, if any.
>
> Christopher
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).
signature.asc
Description: PGP signature
