On Fri, 5 Jul 2024 at 21:55, Alejandro Colomar <alx@xxxxxxxxxx> wrote:
>
> On Fri, Jul 05, 2024 at 09:28:46PM GMT, Jonathan Wakely wrote:
> > > 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.
>
> Let me be a little bit sarcastic.
>
> If so, let's take down -Wrestrict at all, because it triggers false
> positives at the same rate. How is it even in -Wall and not just
> -Wextra?
>
> Here's a false positive:
>
> $ cat d.c
> int is_same_pointer(const char *restrict ca, char *restrict a)
> {
> return ca == a;
This is a strawman argument, because all your example functions have
been pretty useless and/or not good uses of restrict.
Yes, if you put restrict on functions where you don't ever access any
objects through the pointers, the restrict qualifiers are misleading
and so compilers might give bad warnings for your bad API.
> }
>
> int main(void)
> {
> char x = 3;
> char *xp = &x;
> is_same_pointer(xp, xp);
> }
> $ cc -Wall d.c
> d.c: In function ‘main’:
> d.c:10:9: warning: passing argument 2 to ‘restrict’-qualified parameter aliases with argument 1 [-Wrestrict]
> 10 | d(xp, xp);
> | ^~~~~~~~~~~~~~~
>
> It's impossible to know if a use of restrict causes UB without reading
> both the source code of the caller and the callee, so except for
> -fanalyzer, it's impossible to diagnose something with certainty.
>
> So, it's certainly not something we want in -Wall.
>
> Or should I remove the 'restrict' qualifier from that function, loosing
> "precious" semantic information, just because the compiler doesn't like
> it?
>
> Cheers,
> Alex
>
>
> --
> <https://www.alejandro-colomar.es/>
