Re: Possible non-compliance of the restrict keyword contract in coreutils/touch.c

[Paul Eggert]

On 7/27/22 12:27, Bruno Haible wrote:

> We had this discussion already in Feb 2020:

Oh, thanks for reminding me; I'd quite forgotten.


> what we need is not to add more 'restrict' here and
> there, but rather an understandable (and still correct) explanation of
> what 'restrict' means, including for const pointers and array members.
> If stackoverflow is possibly not the right medium for this explanation,
> then possibly the GNU C manual [6] is?

I looked into this a bit more, and it turns out that GCC was wrong about 
what happens when some parameters have 'restrict' and others do not, and 
this was partly because the C Standard itself is so opaque. (The GCC bug 
has been fixed.)

In 2018 Troy Johnson and Bill Homer of Cray proposed[1] adding examples 
to the C standard to try to make it clearer what happens when some 
function parameters are 'restrict' and others are not. These examples 
have been added (with some changes) to section 6.7.3.1 of the current 
(June 2022) draft of the next C standard.[2] Perhaps they will help 
explain things better.

The confusion in this obscure area for so many years suggests that 
Gnulib would be better off following the lead of POSIX and the C 
standard, by using 'restrict' on all relevant parameters rather than 
trying to be clever and use 'restrict' with only some parameters. 
Although omitting some 'restrict's shortens the code, it complicates 
analysis (for both humans and compilers) so much that it's more trouble 
than its worth.

[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2260.pdf
[2] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2912.pdf