Thanks to Paul and all for the enlightening discussion about what 'restrict' actually means.
What I intend to do it gnulib is: * In the function *definitions*, do not use 'restrict' at all. Rationale: - Gnulib code is not time-critical. 'restrict' enables micro- optimizations, at the price of undefined behaviour for some callers. - Humans have a poor understanding of what 'restrict' means, and the GCC warnings cover only a subset of the undefined behaviour situations (namely, GCC can only warn about equal pointers, but not about overlapping array slices). * In the function *declarations* for POSIX functions, I will use 'restrict' exactly as written in POSIX. Rationale: - 'restrict' modifies the contract between the caller and the implementor of a function. Whatever 'restrict' precisely means, the contract that programmers will look at is the POSIX standard. * In the function *declarations* for non-POSIX functions, I will use 'restrict' when there is a significant benefit, and only on non-const pointer parameters. Rationale: - I want to see useful warnings from GCC. "Useful" means: with the normal programming style; passing 'void *' arguments to functions that expect 'char *', 'FILE *', etc. is not the normal programming style I want to care about. - The semantics of 'restrict' is a bit confusing, and the semantics of 'restrict' on const pointer parameters is additionally confusing. - It is typically sufficient - both for warnings and optimization - to put 'restrict' on the non-const pointer parameters only. Bruno