From owner-freebsd-standards@freebsd.org Wed Feb 21 10:44:18 2018 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8171DF1C787; Wed, 21 Feb 2018 10:44:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF83672198; Wed, 21 Feb 2018 10:44:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w1LAi1SB084085 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Feb 2018 12:44:04 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w1LAi1SB084085 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w1LAi0xC084083; Wed, 21 Feb 2018 12:44:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 21 Feb 2018 12:44:00 +0200 From: Konstantin Belousov To: Eitan Adler Cc: Warner Losh , Kevin Lo , FreeBSD Standards , FreeBSD Hackers Subject: Re: Marking select(2) as restrict Message-ID: <20180221104400.GU94212@kib.kiev.ua> References: <20180221032247.GA81670@ns.kevlo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 10:44:18 -0000 On Tue, Feb 20, 2018 at 10:14:05PM -0800, Eitan Adler wrote: > On 20 February 2018 at 21:19, Warner Losh 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.