Date: Thu, 22 Feb 2018 22:27:46 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Garrett Wollman <wollman@csail.mit.edu> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-standards@freebsd.org Subject: Re: Marking select(2) as restrict Message-ID: <20180222212746.GB58772@stack.nl> In-Reply-To: <23181.54825.511195.393054@khavrinen.csail.mit.edu> References: <20180221032247.GA81670@ns.kevlo.org> <CAF6rxg=WwqeBnmJzfOZgtwrYesXPfvJFeaVmQwtTa_89_sxaJg@mail.gmail.com> <CANCZdfo46bhfaRpbqOmJjk4%2B=1R2c5kvmrJPENaxNgK==5M4kg@mail.gmail.com> <CAF6rxg=wNVgDUF9o744ngmzPNeHB3hqdrLufy=yS3D4osczxFQ@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 21, 2018 at 03:27:21PM -0500, Garrett Wollman wrote: > <<On Wed, 21 Feb 2018 22:10:02 +0200, Konstantin Belousov <kostikbel@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180222212746.GB58772>