Am Mittwoch, dem 07.10.2026 um 22:42 +0200 schrieb Alejandro Colomar: > Hi Joseph, > > > Date: 2026-10-07 20:17:49+0000 > > From: Joseph Myers <[email protected]> > > > > On Tue, 6 Oct 2026, Alejandro Colomar wrote: > > > > > > So when you introduce this interaction by adding _Countof on array > > > > parameters, you need to (a) work out the desired semantics, (b) > > > > document > > > > them, (c) implement them and (d) ensure they are properly covered in > > > > the > > > > testsuite. (Even defining as "not permitted on any parameter with a > > > > forward declaration" to avoid these issues could be awkward when you > > > > might > > > > not know at the point _Countof is encountered whether a previous > > > > parameter > > > > referenced will turn out to be a forward declaration or not.) > > > > > > I've been thinking about this, now that it's more or less certain that > > > forward parameter declarations won't be standardized. > > > > > > I still refuse to define the behavior. I think it's something a > > > programmer simply shouldn't use at all, and thus a contract for it is > > > bad. However, I agree it's unnecessarily hostile to make it UB. > > > > When a programmer shouldn't use it at all, that's an argument for defining > > strict rules (making problem cases into errors, and documenting and > > testing that), rather than leaving it unspecified. > > The strict rules would be that it's a constraint to have the forward > declaration of a parameter contradict the declaration, and thus a > constraint violation. However, implementing those diagnostics would be > non-trivial for me. > > Here's a case which is supported by GCC 16, and which should be > a constraint violation: > > alx@devuan:~/tmp$ cat cap.c > int > f(int n, int a[][n]; int n, int a[][n+1]) > { > return _Countof(a[0]); > } > > int > main(void) > { > int a[42]; > > return f(42, &a); > } > alx@devuan:~/tmp$ /opt/local/gnu/gcc/maxof8/bin/gcc -Wall -Wextra > cap.c > alx@devuan:~/tmp$ ./a.out > alx@devuan:~/tmp$ echo $? > 43 > > Would you be able to add a diagnostic for that? > We should also diagnose the following one: > > int > g(int n, int m, int a[][n]; int n, int m, int a[][m]) > { > return _Countof(a[0]); > } > > But can we really diagnose this? Is there code in the compiler for > figuring out whether we can prove that these expressions will evaluate > to the same value always or not?
Not in general, but we can still warn in simpler cases as we do for redeclarations of the function itself. int foo(int n, char buf[n]); int foo(int n, char buf[n + 1]); https://godbolt.org/z/eadanMrxd Probably the same logic could be used for inconsistencies with forard declarations. For semantics of _Countof, I would agree that making it unspecified which bound is used in case of inconsistencies is the best thing to do for now. Martin > > > Have a lovely night! > Alex
