Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 5 Jul 2024 at 21:26, Martin Uecker <muecker@xxxxxxx> wrote:
>
> Am Freitag, dem 05.07.2024 um 21:28 +0200 schrieb Alejandro Colomar:
>
> ...
> >
> > > > Showing that you can contrive a case where a const char* restrict and
> > > > char** restrict can alias doesn't mean there's a problem with strtol.
> > >
> > > I think his point is that a const char* restrict and something which
> > > is stored in a char* whose address is then passed can alias and there
> > > a warning would make sense in other situations.
> >
> > Indeed.
> >
> > > But I am also not convinced removing restrict would be an improvement.
> > > It would make more sense to have an annotation that indicates that
> > > endptr is only used as output.
> >
> > What is the benefit of keeping restrict there?  It doesn't provide any
> > benefits, AFAICS.
>
> Not really I think.  I am generally not a fan of restrict.
> IMHO it is misdesigned and I would like to see it replaced
> with something better.  But I also not convinced it really
> helps to remove it here.
>
> If we marked endptr as "write_only" (which it might already
> be) then a future warning mechanism for -Wrestrict could
> ignore the content of *endptr.


That seems more useful. Add semantic information instead of taking it
away. If the concern is a hypothetical future compiler warning that
would give false positives for perfectly valid uses of strtol, then
the problem is the compiler warning, not strtol. If additional
information can be added to avoid the false positives (and also
possibly optimize the code better), then that wouldn't require a
change to the standard motivated by a hypothetical compiler warning.




[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux