Hi Martin, Joseph, > Date: 2026-10-09 14:07:18+0200 > From: Martin Uecker <[email protected]> > [...] > > Hmmm, this could work, although it could be surprising and dangerous to > > remove it, because then fortification would be degraded, right? > > > > I think it might be better to disallow it. > > > > So, let's see alternatives we have not fully discarded yet (in no > > particular order): > > > > > > - Make it unspecified which of the array length expressions is used. > > This would be my first choice. > > > > > - Disallow using _Countof() on array parameters where the array length > > is specified in a forward declaration. > > > > The easiest way to implement this is to interpret > > > > void f(int a[42]; int a[42]); > > as > > void f(int a[42]; int a[]); > > > > which will obviously disallow _Countof(). > > This could be dangerous, as we'd be degrading fortification > > information. > > Isn't this the same as what I proposed above?
Yup; I was summarizing, to have a complete list of alternatives. This
is indeed literally what you propose.
> > - Disallow specifying an array length if it has been specified before.
> >
> > Diagnose the following:
> >
> > void f(int a[42]; int a[42]);
> >
> > (even when not using _Countof()!)
> > This is a breaking change, but chances are quite low of actually
> > having code that does this. Other than potentially requiring
> > changes to existing code, it should be fine and safe.
> >
>
> It is a weird rule though that makes zero sense by itself.
The idea is that why would you put the length earlier? It doesn't seem
useful, so disallowing it isn't crazy.
It's similar to the recent addition of a diagnostic for when using more
than one list of forward declarations of parameters; they're unnecessary
and thus diagnosed.
> > We could continue allowing this:
> >
> > void f(int a[42]; int a[]);
> >
> > (but _Countof() would fail.)
> > The specification of _Countof() would be that it is not allowed
> > if the array length was specified in a forward declaration.
> >
>
> Why would you not allow _Countof in this case? We currently allow
> this:
>
> int f(int n, int (*p)[n]; int (*p)[], int n)
> {
> return _Countof *p;
> }
Oh! I thought we didn't allow this. I thought the second one shadowed
the first one and forgot the length.
alx@debian:~/tmp$ cat c.c
int
f(int (*p)[7]; int (*p)[])
{
return _Countof(*p);
}
alx@debian:~/tmp$ gcc -Wall -Wextra -S c.c
alx@debian:~/tmp$
You're right, so that would be allowed, and for consistency, it would
also be allowed for array parameters.
> > I think I've covered them all.
> >
> > I prefer the 3rd alternative, then the 1st, and I'd like to avoid the
> > 2nd. What do you think about them? Did I miss any other alternative?
> >
>
> Personally, I would prefer the first as this is the most simply
> and does not affect any existing or plausible use case.
I agree. If Joseph is okay with it, let's go that way.
I'll summarize again, fixing what you reported:
- Make it unspecified which of the array length expressions is used.
Martin's preference.
Also my preference.
- Disallow using _Countof() on array parameters where the array length
is specified in a forward declaration.
Not easy to implement.
The easiest way to implement this is to interpret
void f(int a[42]; int a[42]);
as
void f(int a[42]; int a[]);
and forget array length.
This could be dangerous, as we'd be degrading fortification
information.
Idea suggested by Joseph, and
Implementation suggested by Martin.
- Disallow specifying an array length if it has been specified before.
Diagnose the following:
void f(int a[42]; int a[42]);
(even when not using _Countof()!)
This is a breaking change, but chances are quite low of actually
having code that does this. Other than potentially requiring
changes to existing code, it should be fine and safe.
Martin seems against this.
The 2nd alternative is still my least favourite one, because I fear it
may degrade safety, due to forgetting bounds.
The 3rd alternative is disliked by Martin, but I think it can make sense
to diagnose it, since I don't think it's ever useful. Similar to the
diagnostic for multiple lists of fwd decls, a diagnostic for this seems
reasonable.
The 1st alternative (keeping it unspecified) seems to be the least
problematic one, and at the same time the easiest to implement
(actually, it's the current implementation; it'd only need documentation
changes).
Because of being unspecified, we still have the right to add diagnostics
in the future, if we find a way to add them.
Joseph, would it be acceptable to you to have it unspecified?
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
