Marking select(2) as restrict
kostikbel at gmail.com
Wed Feb 21 10:44:18 UTC 2018
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
> > 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
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.
More information about the freebsd-standards