Marking select(2) as restrict

Mark Millard marklmi26-fbsd at
Sun Feb 25 14:47:03 UTC 2018

On 2018-Feb-24, at 5:28 PM, Bruce Evans <brde at> wrote:

> On Sat, 24 Feb 2018, Warner Losh wrote:
>> On Sat, Feb 24, 2018 at 11:55 AM, Conrad Meyer <cem at> wrote:
>>> On Sat, Feb 24, 2018 at 10:35 AM, Eitan Adler <lists at>
>>> wrote:
>>>> After this entire thread here is the summary. If I've misrepresented
>>>> you here please let me know.
>>>> ...
>>>> kib@ - no benefit; concerned fallout could be hard to observe
>>>> cem@ - concerned about warnings
>>> Consider me a +1 to kib at .  I did not voice those concerns explicitly
>>> in earlier email because kib did already and I didn't anticipate you
>>> would ignore him.
>> So there's no benefit to the change (we won't optimize better). It's hard
>> to observe breakage. No answer about how we'd even know if something broke
>> because a exp run sure as hell isn't going to tell us.
>> All that militates against the change rather strongly. Your exp run will
>> change no minds because it is useless.
> Why not remove restrict from other APIs to be consistent with select()?  If
> might break their callers just as much.

This appears to be about the handling of non-conforming programs. Quoting
from C99's 6.7.3 "Type qualifiers" paragraph 7 about conforming programs:

"The intended use of the restrict qualifier (like the register storage
class) is to promote optimization, and deleting all instances of the
qualifier from all preprocessing units composing a conforming program
does not change its meaning (i.e. observable behavior)."

So: If removing restrict results in a conforming program's observable
behavior changing, then that would be evidence that the environment is
incorrectly implemented relative to C99.

Of course, removing restrict can make it harder to detect non-conforming
programs if the compiler(s) involved are helpful when restrict is

Going the other way: "Formal definition of restrict" also says in its paragraph 6:

"A translator is free to ignore any or all aliasing implications of
uses of restrict."

Mark Millard
marklmi at
( markmi at is
going away in 2018-Feb, late)

More information about the freebsd-standards mailing list