Date: Mon, 22 Sep 1997 00:39:42 +0100 (BST) From: Niall Smart <nsmart@iona.com> To: Terry Lambert <tlambert@primenet.com> Cc: Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free Message-ID: <Pine.SOL.3.96.970922002812.25710A-100000@ultra> In-Reply-To: <199709192002.NAA29627@usr03.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 19 Sep 1997, Terry Lambert wrote: > > > > Which is why I save and restore errno in signal handlers. > > > Perhaps this should be done by the trampoline code on the user's > > > behalf... > > Perhaps that would encourage people to write non-portable code. > > When a read or write fault occurs on page zero in a program running > on SVR4, rather than crashing, the map the page and note the effect. > > There is a kernel tunable that can turn this off, but a great many > legacy programs dereference NULL pointers, expecting a NULL pointer > to be identical to a NULL string. > > The default for SVR4 is arguably incorrect, but it follows the principle > of least astonishment, and allows legacy code to run. I don't mind, as long as it isn't documented. :) Transparent support for legacy/bad code is acceptable, documented unportable behaviourisms aren't, IMO. Even if you note that they are unportable (some) people will still rely on them, I would prefer to see the documentation advising people that they should save and restore errno in signal handlers regardless of the actual behaviour. -- Niall Smart Customer Engineering, IONA Technologies. (www.iona.com) >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.3.96.970922002812.25710A-100000>