Marking select(2) as restrict

[Konstantin Belousov]

On Wed, Feb 21, 2018 at 03:27:21PM -0500, Garrett Wollman wrote:
> <<On Wed, 21 Feb 2018 22:10:02 +0200, Konstantin Belousov <kostikbel at gmail.com> said:
> 
> > Undefined != broken, whatever some compiler vendors try to bluff.
> 
> No, undefined behavior means the application is wrong.  Literally
> anything may happen; the compiler does not enter into it.  The
> compiler is not involved when you free() a pointer into the stack, or
> pass a null pointer into a library routine that unconditionally
> dereferences it, or update a string literal; nor is it involved when
> you pass pointers that alias to a library routine that expects them to
> point to different objects.
Undefined behavior only means that the outcome was not specified in
some Sacred Text. If your world is limited by that Text, then of course
it is quite bad to have undefined behavior. If you look outside the
Text bounds, then it often appears that something was left undefined to
provide better portability, where different platforms have different
but quite reasonable and intuitive specifications. Best example is the
signed integer overflow, which was clearly left undefined to allow other
than two-complement representations, and not to allow the parodoxical
code transformations. For each integer representation allowed in the C
standard, signed overflow, if taken naturally, is very much defined. Or
the stuff is undefined due to the omission, etc.

It is attempts to provide a retionale explanation to decisions of
the compiler writers which clearly contradict to the goals of most
programmers to write reliable software based on the expected behavior
that makes the situation so confusing. In fact, compiler authors do have
their own goals of winning the 0.1% in corner cases of speed tests, and
do not care about usability.

Sorry for the long rant.
> 
> In the particular case of select(), there are no guarantees as to the
> order in which the fd_set objects pointed to by readfds, writefds, and
> exceptfds will be updated, so applications which alias them are
> clearly wrong and have been since this interface was introduced in
> 4.2BSD.

No, the worry about restrict in the select(2) declaration should be not
about the copyout order.  It is more the compiler brokeness which makes
things crazy, see above.

Compiler would note that some pointers cannot be equal or even point to
the overlapping memory regions because they are supplied as restricted
arguments to select(2), and this allows it to make conclusions which
break the program logic.