From owner-freebsd-hackers Mon Feb 26 14:21:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id 43C7137B401 for ; Mon, 26 Feb 2001 14:21:10 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1QML9621604 for ; Mon, 26 Feb 2001 16:21:09 -0600 (CST) Message-Id: <200102262221.f1QML9621604@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Mon, 26 Feb 2001 19:18:57 -0300." Date: Mon, 26 Feb 2001 16:21:09 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Rik van Riel writes: >I don't think a failed kernel-level allocation after overcommit >should generate a segfault. >IMHO it should send a bus error (or a sigkill if the process >doesn't exit after the SIGBUS). Same difference, so far as the language is concerned. >Rationale: >SIGSEGV for _user_ mistakes (process accesses wrong stuff) >SIGBUS for _system_ errors (ECC error, kernel messes up, ...) As long as we grant that it's the kernel *messing up*, I won't complain; no one said an implementation could be perfect, and known bugs go with the territory. I only object to attempts to portray it as a legitimate and correct implementation of the C spec. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message