[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: restrict

From: Paul Eggert
Subject: Re: restrict
Date: Mon, 17 Feb 2020 14:28:00 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]