Marking select(2) as restrict

Tijl Coosemans tijl at
Mon Feb 26 12:46:42 UTC 2018

On Mon, 26 Feb 2018 21:00:21 +1100 (EST) Bruce Evans <brde at> wrote:
> For select() with restrict, I think the compiler cannot assert that
> the args don't overlap since (even without the detailed specification
> and Example 3), the compiler cannot know if select() modifies its args.
> For all that the compiler knows, select() might be a stub that never
> modifies or even reads anything.  I think doing no accesses satifies
> the constraints of restrict.  It might be valid for the compiler to
> assert that the (values pointed to by) the fdset args don't change for
> select(nfd, &fdset, &fdset, &fdset, &tv) (because any write access
> through an fdset type would give undefined behaviour on the other fdset
> args; tv can still change since it has a different type).  But this is
> precisely what is wanted for the original example where we only care
> about the return value -- then fdset is indeterminate after the call
> so we shouldn't use it; the compiler is unlikely to optimize the non-use
> of it and the worst that it can do is add a runtime assertion that the
> arg didn't change.

I don't think the compiler can assert that fdset is unmodified.  It's
valid for select to modify fdset through one pointer if it doesn't
dereference the other two.

More information about the freebsd-standards mailing list