Re: restrict - summary

[Bruno Haible]

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