Am Donnerstag, dem 14.08.2025 um 14:05 +0200 schrieb Alejandro Colomar:
> Hi Martin,
>
> On Thu, Aug 14, 2025 at 01:37:55PM +0200, Martin Uecker wrote:
> > Am Donnerstag, dem 14.08.2025 um 12:19 +0200 schrieb Alejandro Colomar:
> > > Hi Martin,
> > >
> > > On Thu, Aug 14, 2025 at 11:01:05AM +0200, Alejandro Colomar wrote:
> > > > +void
> > > > +decay_obvious (int a[2])
> > > > +{
> > > > + _Countof (typeof (a)); /* { dg-error "invalid" } */
> > > > + _Countof (a + 1); /* { dg-error "invalid" } */
> > >
> > > It didn't occur to me the following test:
> > >
> > > alx@devuan:~/tmp$ cat c.c | nl -ba
> > > 1 int
> > > 2 main(int argc, char *argv[argc + 1])
> > > 3 {
> > > 4 argv++;
> > > 5
> > > 6 return _Countof(argv);
> > > 7 }
> > > alx@devuan:~/tmp$ /opt/local/gnu/gcc/countof_ap/bin/gcc -Wall -Wextra
> > > c.c
> > > alx@devuan:~/tmp$ ./a.out
> > > alx@devuan:~/tmp$ echo $?
> > > 2
> > >
> > > This is a weak point, which requires -farray-parameters-are-const as
> > > proposed in:
> > > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121271>
> > >
> > > I'm willing to accept it as a known limitation of _Countof(), and
> > > tell that programmers to use const (or use -farray-parameters-are-const
> > > once we provide it) to ensure safety.
> >
> > You could also add a warning when _Countof is applied to a
> > non-constant pointer.
>
> Yup, I should add that. I wouldn't enable it in any groups flags,
> though. I don't want people to start writing [const n]. Instead,
> I expect them to use -farray-parameters-are-const in the future.
Or a warning when array parameters are modified. I think this would
make the most sense at the moment.
> > > So, I stand by this patch even with this known limitation.
> > >
> > > On the other, hand, it may be a GCC existing bug? I see that
> > > _Countof(a+0) remembers the array number of elements but _Countof(a+1)
> > > doesn't. Maybe once you do a++ you should also forget the number of
> > > elements (or update it)?
> >
> > Difficult, as this is then flow-sensitive and not simply a
> > property of 'a'. That a + 0 works because the expression
> > is folded before. Maybe you could change it to take the expression
> > before folding?
>
> Hmmm, yeah, that would be good. It would fix the _surprise() test
> cases. Do you expect any issues by removing the call to c_fully_fold()?
In the code path where we have a PARM_DECL, it is not needed.
Otherwise it is.
Martin
