Am Montag, dem 19.01.2026 um 23:59 +0100 schrieb Alejandro Colomar: > Hi Martin, > > On Mon, Jan 19, 2026 at 06:22:15PM +0100, Martin Uecker wrote: > > Am Montag, dem 19.01.2026 um 16:53 +0000 schrieb Joseph Myers: > > > On Sun, 18 Jan 2026, Alejandro Colomar wrote: > > [...] > > > > int (*)[2] > > > int (*)[3] > > > int (*)[] > > > > > > for the same parameter would be valid because the two forward > > > declarations > > > are compatible with the final declaration. But at present such a > > > combination isn't accepted (and I think it shouldn't be accepted, i.e. > > > the > > > compiler is right to reject it). > > > > IMHO it should work as elsewhere. Later declarations should be > > compatible with the previous ones and we form the composite type > > each time. > > We could. However, unless that simplifies the implementation, it might > not be worth the effort. I don't expect composite types to be useful > for any real code in forward declarations.
I think it does simplify the implementation and it gives clear semantics. Especially if we later improve warnings at run-time checks, it would be ideal if it is based on common infrastructure as much as possible and not specialized code for just this. Martin > > Considering that we already diagnose more than one forward declaration > of a parameter (-Wextra), this would be already rare, and thus just > caring about one pair would be enough. If one wants to ignore the > diagnostic, and wants to run a program with > > void f(int (*a)[2]; int (*a)[*]; int (*a)[3]; int (*a)[]); > > they get what they asked for: UB. > > But if you want to implement it, I won't oppose it. > > > > Whatever is documented should also come with thorough testcases (which > > > might mean adjusting the compiler to behave in whatever way we agree is > > > desired). > > > > > > Furthermore, _Countof for array parameters *does* introduce new issues > > > because compatibility above can only refer to the types *after* > > > adjustment, but with _Countof the question of matching lengths *before* > > > adjustment comes into play (and with it, the concern about whether adding > > > new UB relating to something that doesn't affect types at all is > > > desirable). So it needs to come with appropriate documentation of the > > > semantic model involved. > > > > I think I am in favour of applying the same rules before adjustment even if > > this introduces new UB (but inside GCC's extension), because this is > > ultimately more consistent and useful. > > > > We should try to diagnose obvious inconsistencies at compile time > > if possible. > > I'll document our already extended meaning of array parameters. That > should cover this. > > > Have a lovely night! > Alex > > > > > > > > > In all cases, if the forward declarations appear in a function > > > definition, > > > there is also the question of whether the array length expressions in > > > forward declarations (including lengths of arrays adjusted to pointers) > > > get evaluated for their side effects on entry to the function. I believe > > > they should be; this ought to be documented and tested. > > > > I agree. > > > > Martin > > > >
