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/>