Hi everyone,
while testing a new buffer overlap and restrict checker in the analyzer,
it emitted a warning inside coreutils. During the discussion [0], Paul
Eggert posted a link to the current draft of the next C standard [1]
with new examples for the definition of 'restrict'. Especially example 3
in 6.7.3.1 is interesting:
void h(int n, int * restrict p, int * restrict q, int * restrict r)
{
int i;
for (i = 0; i < n; i++)
p[i] = q[i] + r[i];
}
The draft says that a call h(100, a, b, b) is *defined* behavior because
'b' is never modified inside the method. That brings up the question how
GCC should handle this. At the moment, Wrestrict (and my new
Wanalyzer-restrict) warns on defined behavior:
/path/to/main.c:70:13: warning: passing argument 3 to ‘restrict’-qualified
parameter aliases with argument 4 [-Wrestrict]
70 | h(100, a, b, b);
| ^ ~
But finding out that 'q' and 'r' are never modified needs a pass over
the callee. Further, when the callee implementation isn't available at
the point Wrestrict runs, we couldn't emit a warning at all if we don't
want any false positive.
I thought maybe a tradeoff would be to keep warning without checking for
writes on parameters in the callee but additionally issue a fix-it hint
that if the memory location the parameter points to is never written, to
add the points-to const type qualifier.
The addition of the const qualifier simplifies deducing that the
memory location the parameter point to is never written for Wrestrict
and already silences the warning.
What do you think?
- Tim
[0] https://lists.gnu.org/archive/html/bug-gnulib/2022-07/msg00066.html
[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2912
