From owner-freebsd-bugs Sun Sep 21 16:40:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA25157 for bugs-outgoing; Sun, 21 Sep 1997 16:40:34 -0700 (PDT) Received: from dublin.iona.ie (root@operation.dublin.iona.ie [192.122.221.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA25152; Sun, 21 Sep 1997 16:40:30 -0700 (PDT) Received: from ultra (ultra [192.122.221.136]) by dublin.iona.ie (8.7.5/jm-1.01) with SMTP id AAA00984; Mon, 22 Sep 1997 00:40:06 +0100 (BST) Date: Mon, 22 Sep 1997 00:39:42 +0100 (BST) From: Niall Smart X-Sender: nsmart@ultra To: Terry Lambert cc: Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free In-Reply-To: <199709192002.NAA29627@usr03.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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) >