Am Montag, dem 19.01.2026 um 16:53 +0000 schrieb Joseph Myers: > On Sun, 18 Jan 2026, Alejandro Colomar wrote: > > > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi > > index b4879b3d82ff..48166d44546e 100644 > > --- a/gcc/doc/extend.texi > > +++ b/gcc/doc/extend.texi > > @@ -711,8 +711,15 @@ just like in the regular list of parameter > > declarations. > > You can write any number of lists of parameter forward declaration, > > but using more than one is unnecessary. > > The last semicolon is followed by the list of parameter declarations. > > -Each parameter forward declaration must match > > -a parameter declaration in parameter name and data type. > > + > > +Each parameter forward declaration must > > +match a parameter declaration in parameter name > > +and must be compatible with its type. > > Compatible with only the final parameter declaration, or do they also need > to be compatible with each other? As written, the three types > > 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. > > 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. > > 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
