[Top][All Lists]

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

Re: restrict - summary

From: Bruno Haible
Subject: Re: restrict - summary
Date: Mon, 17 Feb 2020 22:19:44 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-171-generic; KDE/5.18.0; x86_64; ; )

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.

      - Gnulib code is not time-critical. 'restrict' enables micro-
        optimizations, at the price of undefined behaviour for some
      - 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.

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

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


reply via email to

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