Hi Martin, > Date: 2026-10-07 23:11:02+0200 > From: Martin Uecker <[email protected]> > > 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.
If we can't warn always, then it can't be a constraint, which leaves us
with the following alternatives:
- Define the behavior.
I refuse to do this, because it's erroneous behavior.
- Make it UB.
IIRC, Joseph complained that this was unnecessarily hostile.
- Leave it unspecified which of the expressions are used.
This is a compromise between not wanting to define the behavior
and not wanting to invoke nasal demons.
- Add a simpler (but more restrictive) constraint.
We could simply prohibit declaring array lengths in forward
declarations.
I prefer the unspecified behavior, and secondarily, the simpler
constraint.
>
> 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.
Yup.
Have a lovely day!
Alex
>
> Martin
>
>
> >
> >
> > Have a lovely night!
> > Alex
--
<https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
