Re: restrictness of strtoi(3bsd) and strtol(3)

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

Hello Amol,

On Sun, Dec 03, 2023 at 04:29:07PM +0530, Amol Surati wrote:
> The section "7. Library" at [1] has some information about the 'restrict'
> keyword.
> 
> I think the restrict keywords compel the programmer to keep the string
> (or that portion of the string that strtol actually accesses) and the
> pointer to a string in non-overlapping memory regions. Calling
> strtol(p, &p, 0) should be well-defined in such cases.

That would justify the restrict on char **restrict, but it doesn't
justify the const char *restrict.

I think a more appropriate prototype would be

	long
	strtol(const char *nptr, char **restrict endptr, int base);

The above means that endptr points to memory that is not pointed to by
anything else in this call.

But any of the following is somewhere between confusing and a lie:

	long
	strtol(const char *nptr,
	       char *restrict *restrict endptr,
	       int base);

	long
	strtol(const char *restrict nptr,
	       char **restrict endptr,
	       int base);

	long
	strtol(const char *restrict nptr,
	       char *restrict *restrict endptr,
	       int base);

These 3 from above all mean the same thing: nptr, endptr, and *endptr
each point to a different memory region.  That's of course a lie,
because nptr and *endptr may alias.  The formal definition by ISO C,
which is in terms of accesses, seems to be compatible with these uses of
restrict, because as long as the function doesn't access the memory, it
doesn't matter if they overlap.  However, that definition of restrict is
useless IMO, and still doesn't justify why the compiler isn't
complaining at call site, where it can't know that strtol(3) won't
use **endptr.

Cheers,
Alex

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]