Hi Joseph! On 12/7/22 00:57, Joseph Myers wrote: > On Sat, 3 Dec 2022, Alejandro Colomar via Libc-alpha wrote: > >> For example, this would be nonsense (and I honestly don't know what the >> compiler would understand from it): >> >> void broken(int *restrict a, int *b, int *c); >> void broken(int *a, int *restrict b, int *c); > > Qualifiers on parameters in a function declarator that is not part of a > definition of that function have no semantic effect; restrict on function > parameters only has a semantic effect in the definition of the function. > Having restrict in the prototype may not change the semantics, but it is meaningful to the warnings: $ cat restrict.c void broken(int *restrict a, int *b, int *c); void broken(int *a, int *restrict b, int *c); void f(int *restrict p, int *restrict q, int *restrict r) { broken(p, p, q); broken(p, q, p); broken(p, q, r); } $ cc -Wall -Wextra -S restrict.c restrict.c: In function ‘f’: restrict.c:6:9: warning: passing argument 1 to ‘restrict’-qualified parameter aliases with argument 2 [-Wrestrict] 6 | broken(p, p, q); | ^~~~~~ restrict.c:7:9: warning: passing argument 1 to ‘restrict’-qualified parameter aliases with argument 3 [-Wrestrict] 7 | broken(p, q, p); | ^~~~~~ By not having semantic effect you mean that the compiler (optimizer) won't take advantage of those if the prototype with restrict is seen in the translation unit where the function definition is compiled, given that the function definition doesn't specify restrict? Whatever is the semantic result, I believe GCC should have a warning for mismatching restrict qualifiers. The above doubt is reasonable, and a warning would help make sure that it's not relevant, because code should't do that normally, and with the help of the warning, that can be enforced. Cheers, Alex --