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