On 2/17/20 12:55 PM, Bruno Haible wrote:
it's pretty rare that people use 'void *' pointers and cast them
to pointers of different types.
It's not rare in some of the code I write. :-) Plus, my example had no casts.
Also, even a small variation of this code does not produce a warning any more:
Interesting. I don't see why GCC doesn't warn there.
GCC's heuristics for generating warnings must be even trickier than what's in
the C standard about 'restrict' - which is another reason not to base code off
when exactly GCC warns.
Actually, GCC doesn't warn here, even with 'restrict', because the 3rd argument
is a const-pointer and the 4th argument, being variadic, is treated like a
const-pointer as well.
Fair enough, but there are similar examples where 'restrict' will still be
useful, such as if the 3rd argument is not a const-pointer.
Given the confusion around what 'restrict' is actually about,
the "signal to humans" is fuzzy.
Using 'restrict' in a nonstandard way will make that signal even fuzzier. It's
better to be systematic about it, and to use the same system that the C standard
and POSIX do.
Like Dennis Ritchie and 'noalias'[1], I'm not a big fan of 'restrict'. But we
have it and it's standardized and it's better to use it as intended rather than
invent a not-quite-the-same use for it.
I meant the "glibc bug" the other way around: Someone could tell the glibc
people
that it makes sense to _add_ 'restrict' to the declarations of splice,
printf_arginfo_size_function, openpty, re_set_registers, copy_file_range.
Yes, that would be worth doing.
[1] https://www.lysator.liu.se/c/dmr-on-noalias.html
