Hi Joseph, On Thu, Aug 14, 2025 at 10:03:00PM +0000, Joseph Myers wrote: > On Thu, 14 Aug 2025, Alejandro Colomar wrote: > > > And I'm proposing it as a GNU extension, which means we don't even need > > to care about what ISO C says about [n]. We, as a quality > > implementation, treat it with stronger semantics, which this patch uses. > > As a GNU extension, it's also necessary to define semantics in the > presence of parameter forward declarations.
I'd say that if there are conflicting declarations the behavior is
undefined. So, if you have [2] and [3], think again what you're doing.
That way we keep it simple, and can come back to it later.
After all, why would anyone do that?
Similarly, we should diagnose this:
alx@devuan:~/tmp$ cat fwd.c | nl
1 int
2 fwd(int a[2]; int a[3])
3 {
4 return 0;
5 }
alx@devuan:~/tmp$ gcc -S -Wall -Wextra fwd.c
fwd.c: In function ‘fwd’:
fwd.c:2:19: warning: unused parameter ‘a’ [-Wunused-parameter]
2 | fwd(int a[2]; int a[3])
| ~~~~^~~~
Probably, by fixing that diagnostic, we'd get an improved _Countof().
The current implementation (which is not about _Countof(), but about how
we store the bounds information of array parameters) seems to keep the
last declaration seen, which within the undefined or unspecified
behavior, seems to be a reasonable one.
> > > (And as noted on the
> > > reflector, it would seem desirable to get to a conclusion on revisions of
> > > N2906 and N3605 before considering such a proposal, rather than chaining
> > > new proposals on other proposals still needing significant work.)
> >
> > Those would affect a future implicit deduction of the array length with
> > default arguments. That would need to be careful about composite type,
> > because the caller sees the composite type. However, the function
> > declarator doesn't care about other compatible declarators. It should
> > not affect this feature.
>
> N3605 is definitely relevant even with a single declaration and no
> composite types, because it may determine what's valid regarding the
> parameter name in parentheses or returned by _Generic.
I don't see the relevance. Could you show a piece of code which could
change meaning?
I only see that slight differences in what's accepted or not could
happen, but that's something we should be able to adapt, just as we'd
need to adapt many other places. I don't see it being of special
relevance here.
That proposal (n3605) is also not polished enough for merging, from what
I can see, so I don't see why we should wait indefinitely.
Cheers,
Alex
--
<https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
