[Top][All Lists]

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

Re: Possible non-compliance of the restrict keyword contract in coreutil

From: Paul Eggert
Subject: Re: Possible non-compliance of the restrict keyword contract in coreutils/touch.c
Date: Wed, 27 Jul 2022 13:49:01 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

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

reply via email to

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