Date: Wed, 21 Feb 2018 23:53:54 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Garrett Wollman <wollman@csail.mit.edu> Cc: freebsd-standards@freebsd.org Subject: Re: Marking select(2) as restrict Message-ID: <20180221215354.GD94212@kib.kiev.ua> 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. Undefined behavior only means that the outcome was not specified in some Sacred Text. If your world is limited by that Text, then of course it is quite bad to have undefined behavior. If you look outside the Text bounds, then it often appears that something was left undefined to provide better portability, where different platforms have different but quite reasonable and intuitive specifications. Best example is the signed integer overflow, which was clearly left undefined to allow other than two-complement representations, and not to allow the parodoxical code transformations. For each integer representation allowed in the C standard, signed overflow, if taken naturally, is very much defined. Or the stuff is undefined due to the omission, etc. It is attempts to provide a retionale explanation to decisions of the compiler writers which clearly contradict to the goals of most programmers to write reliable software based on the expected behavior that makes the situation so confusing. In fact, compiler authors do have their own goals of winning the 0.1% in corner cases of speed tests, and do not care about usability. Sorry for the long rant. > > 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. No, the worry about restrict in the select(2) declaration should be not about the copyout order. It is more the compiler brokeness which makes things crazy, see above. Compiler would note that some pointers cannot be equal or even point to the overlapping memory regions because they are supplied as restricted arguments to select(2), and this allows it to make conclusions which break the program logic.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180221215354.GD94212>