On Sun, Dec 03, 2023 at 05:33:59PM +0100, Alejandro Colomar wrote:
> But yeah, the point is there: the standard's definition of restrict
> isn't very good.
>
> > The historical docs point towards a decision to stamp the prototype with
> > restrict under the assumption that (1) the string and the pointer to string
> > are in disjoint memory locations,
>
> This justifies the restrict on endptr.
>
> > and (2) the implementations would
> > use endptr for nothing else other than maintaining a position in the given
> > string.
>
> This is quite brittle. The restrict on ntpr should cause the compiler
> to scream. I'll report a missing warning on bugzilla.
Here's a reproducer of the bug:
$ cat restrict.c
long bogus_strtol(const char *restrict s, char **restrict ep, int base);
int
main(void)
{
char buf[3] = "foo";
char *p = buf;
bogus_strtol(p, &p, -42);
}
long
bogus_strtol(const char *restrict s, char **restrict ep, int base)
{
**ep = *s;
return base;
}
$ cc -Wall -Wextra restrict.c -fanalyzer
$ clang -Weverything restrict.c
$ cc -Wall -Wextra restrict.c -fanalyzer -O3
$ clang -Weverything restrict.c -O3
I was expecting to see something, at least from one of the compilers, or
maybe from -fanalyzer, but to my surprise, this bug is completely
unnoticed; both in the call and in the definition. It's time to file a
bug.
--
<https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
