Marking select(2) as restrict

[Eitan Adler]

On 22 February 2018 at 06:43, Warner Losh <imp at bsdimp.com> wrote:
> On Thu, Feb 22, 2018 at 3:56 AM, Konstantin Belousov <kostikbel at gmail.com>
> wrote:
>
>> On Thu, Feb 22, 2018 at 11:27:52AM +0100, Tijl Coosemans wrote:
>> > On Wed, 21 Feb 2018 12:44:00 +0200 Konstantin Belousov <
>> kostikbel at gmail.com> wrote:
>> > > 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.
>> >
>> > FWIW, it seems that glibc uses restrict since 2000 so there's unlikely to
>> > be much fallout:
>> > https://sourceware.org/git/?p=glibc.git;a=blob;f=misc/sys/select.h
>> > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=
>> 98cbe360d947b59e7a5eda068581f4cfeb4b99b3
>>
>> Clearly, nobody knowns.  At least, glibc is used with gcc compilation, not
>> with clang.
>>
>> Consider the recently changed devd code:
>>         select(n + 1, &fd, &fd, &fd);
>> There, compiler can see that restrict is applied to arguments which are
>> given same values.  Since this leads to the self-contradicting statement
>>         fd != fd
>> which cannot be true, compliler in its optimizing wisdom can assume that
>> the code is never executing and remove it.  I do not know whether clang
>> actually makes such transformation, but it does not sound unfeasible
>> looking at its other advances.
>>
>
> If the compilers affirmatively fails when this happens

Compilers cannot fail since errors are only detectable at runtime. The
value of the exp-run is
(a) ensuring that we don't break prototypes of some applications
(b) exercising the applications as much as we can



-- 
Eitan Adler