From owner-freebsd-standards@freebsd.org Thu Feb 22 21:27:48 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 96654F0260D for ; Thu, 22 Feb 2018 21:27:48 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mailout.stack.nl (mailout05.stack.nl [IPv6:2001:610:1108:5010::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.stack.nl", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3321B7A283 for ; Thu, 22 Feb 2018 21:27:48 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from toad2.stack.nl (toad2.stack.nl [IPv6:2001:610:1108:5010::161]) by mailout.stack.nl (Postfix) with ESMTP id 95A2B33; Thu, 22 Feb 2018 22:27:46 +0100 (CET) Received: by toad2.stack.nl (Postfix, from userid 1677) id 915E9892DB; Thu, 22 Feb 2018 22:27:46 +0100 (CET) Date: Thu, 22 Feb 2018 22:27:46 +0100 From: Jilles Tjoelker To: Garrett Wollman Cc: Konstantin Belousov , freebsd-standards@freebsd.org Subject: Re: Marking select(2) as restrict Message-ID: <20180222212746.GB58772@stack.nl> References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> <23181.46427.671514.319710@khavrinen.csail.mit.edu> <20180221185920.GA94212@kib.kiev.ua> <23181.50488.186767.579361@khavrinen.csail.mit.edu> <20180221201002.GC94212@kib.kiev.ua> <23181.54825.511195.393054@khavrinen.csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23181.54825.511195.393054@khavrinen.csail.mit.edu> User-Agent: Mutt/1.8.0 (2017-02-23) 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: Thu, 22 Feb 2018 21:27:48 -0000 On Wed, Feb 21, 2018 at 03:27:21PM -0500, Garrett Wollman wrote: > < 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. > 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. They are wrong, but get away with it if they do not care about the value stored into the fd_set object. Furthermore, adding or removing a restrict qualifier on a parameter does not make the function types incompatible (just like adding or removing a const or volatile qualifier on a parameter; but those are generally used behind a pointer which does make the function type incompatible). Therefore, it would be quite subtle for a missing restrict qualifier to break a build. Although the restrict qualifier imposes restrictions on the pointers the caller can pass, undefined behaviour only results when the callee dereferences them in disallowed ways (some compilers have bugs that make them assume the pointers differ even when never dereferenced for writing). Per the C standard, when the compiler sees aliasing pointers being passed as restrict pointers to an unknown function, it will have to assume the callee only dereferences them in permitted ways (such as not at all, only one of them or only for reading) and can therefore not optimize anything. A blog post about -Wrestrict (which was added in GCC 7) at http://excursionsingcc.blogspot.nl/2016/12/wrestrict.html confirms that the warning can emit false positives. The actual implementation of select() in libc only passes along its arguments to code the compiler cannot see. Therefore, this cannot be optimized either. -- Jilles Tjoelker