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.
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
>
>
--
<https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
