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). 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. 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. -- Joseph S. Myers [email protected]
