Marking select(2) as restrict

[Konstantin Belousov]

On Tue, Feb 20, 2018 at 10:14:05PM -0800, Eitan Adler wrote:
> On 20 February 2018 at 21:19, Warner Losh <imp at bsdimp.com> wrote:
> > Once upon a time, this would break a lot of code. Perhaps times have
> > changed.
> 
> I've seen very little code that this would break though some of it
> certainly exists.
You certainly seen very little code, but the question was about the
existed code.

> 
> > Does the state of the art give warnings,when restrict is violated?
> 
> In the general case it can not since aliasing may occur through
> run-time warnings. Modern compilers can warn in specific sub-cases
> though:
What run-time warnings ?  Point out the code that issues them in the 
case of restrict (or generic aliasing) violation.  In libc ?  In kernel ?

Did you even tried to estimate how many code around still requires disabling
alias analysis to run ?  How does restrict mix with no-aliasing option ?

Above question contains a hint how it is possible to detect existing calls
which violate the restrict specifier for select(2), but this requires
running of all select(2) consumers, on patched kernel or libc/libthr.

> 
> restrict.c:10:6: warning: passing argument 1 to restrict-qualified
> parameter aliases with argument 2 [-Wrestrict]
>   meh(&a, &a);
> 
> > If not,
> > how do you propose the ports broken subtlely be detected?
> 
> My plan was to commit to current but not MFC. This would allow users
> to detect issues and report them.
And, how to do plan to classify the bugs appeared due the change ?
What specific indicators would allow you to find them out in the stream
of the bug reports ?

> 
> Another option is to request that POSIX change the definition of
> select to not require restrict though I am doubtful this will happen.

I fail to find an explanation of the supposed benefit of the change
you proposing.  Please point it out.