Am Freitag, dem 05.07.2024 um 16:37 +0200 schrieb Alejandro Colomar via Gcc: > [CC += linux-man@, since we're discussing an API documented there, and > the manual page would also need to be updated] > > Hi Xi, Jakub, > > On Fri, Jul 05, 2024 at 09:38:21PM GMT, Xi Ruoyao wrote: > > On Fri, 2024-07-05 at 15:03 +0200, Alejandro Colomar wrote: > > > ISO C specifies these APIs as accepting a restricted pointer in their > > > first parameter: > > > > > > $ stdc c99 strtol > > > long int strtol(const char *restrict nptr, char **restrict endptr, int base); > > > $ stdc c11 strtol > > > long int strtol(const char *restrict nptr, char **restrict endptr, int base); > > > > > > However, it should be considered a defect in ISO C. It's common to see > > > code that aliases it: > > > > > > char str[] = "10 20"; > > > > > > p = str; > > > a = strtol(p, &p, 0); // Let's ignore error handling for > > > b = strtol(p, &p, 0); // simplicity. > > > > Why this is wrong? > > > > During the execution of strtol() the only expression accessing the > > object "p" is *endptr. When the body of strtol() refers "nptr" it > > accesses a different object, not "p". > > <http://port70.net/~nsz/c/c11/n1570.html#6.7.3p8> > > Theoretically, 'restrict' is defined in terms of accesses, not just > references, so it's fine for strtol(3) to hold two references of p in > restrict pointers. That is, the following code is valid: > > int > dumb(int *restrict a, int *restrict also_a) > { > // We don't access the objects > return a == also_a; > } > > int > main(void) > { > int x = 3; > > return dumb(&x, &x); > } > > However, in practice that's dumb. The caller cannot know that the > function doesn't access the object, so it must be cautious and enable > -Wrestrict, which should be paranoid and do not allow passing references > to the same object in different arguments, just in case the function > decides to access to objects. Of course, GCC reports a diagnostic for > the previous code: > > $ cc -Wall -Wextra dumb.c > dumb.c: In function ‘main’: > dumb.c:13:21: warning: passing argument 1 to ‘restrict’-qualified parameter aliases with argument 2 [-Wrestrict] > 13 | return dumb(&x, &x); > | ^~ ~~ > > ... even when there's no UB, since the object is not being accessed. > > But when the thing gets non-trivial, as in strtol(3), GCC misses the > -Wrestrict diagnostic, as reported in > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112833>. > > Let's write a reproducer by altering the dumb.c program from above, with > just another reference: > > int > dumb2(int *restrict a, int *restrict *restrict ap) > { > // We don't access the objects > return a == *ap; > } > > int > main(void) > { > int x = 3; > int *xp = &x; > > return dumb2(&x, &xp); > } > > GCC doesn't report anything bad here, even though it's basically the > same as the program from above: > > $ cc -Wall -Wextra dumb2.c > $ strtol does have a "char * restrict * restrict" though, so the situation is different. A "char **" and a "const char *" shouldn't alias anyway. > > Again, there's no UB, but we really want to be cautious and get a > diagnostic as callers, just in case the callee decides to access the > object; we never know. > > So, GCC should be patched to report a warning in the program above. > That will also cause strtol(3) to start issuing warnings in use cases > like the one I showed. > > Even further, let's try something really weird: inequality comparison, > which is only defined for pointers to the same array object: > > int > dumb3(int *restrict a, int *restrict *restrict ap) > { > // We don't access the objects > return a > *ap; > } > > int > main(void) > { > int x = 3; > int *xp = &x; > > return dumb3(&x, &xp); > } > > The behavior is still defined, since the obnjects are not accessed, but > the compiler should really warn, on both sides: > > - The caller is passing references to the same object in restricted > parameters, which is a red flag. > > - The callee is comparing for inequality pointers that should, under > normal circumstances, cause Undefined Behavior. > > > > And if this is really wrong you should report it to WG14 before changing > > glibc. > > Well, I don't know how to report that defect to WG14. If you help me, > I'll be pleased to do so. Do they have a public mailing list or > anything like that? One can submit clarification or change requests: https://www.open-std.org/jtc1/sc22/wg14/www/contributing.html Martin
