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;
}
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/>
Attachment:
signature.asc
Description: PGP signature
