Marking select(2) as restrict

[Mark Millard]

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

> On Sat, 24 Feb 2018, Warner Losh wrote:
> 
>> On Sat, Feb 24, 2018 at 11:55 AM, Conrad Meyer <cem at freebsd.org> wrote:
>> 
>>> On Sat, Feb 24, 2018 at 10:35 AM, Eitan Adler <lists at eitanadler.com>
>>> 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
present.


Going the other way:

6.7.3.1 "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 yahoo.com
( markmi at dsl-only.net is
going away in 2018-Feb, late)