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:
signature.asc
Description: PGP signature
