From owner-freebsd-hackers  Mon Feb 26  6:57:42 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 EFCD237B491
	for <freebsd-hackers@freebsd.org>; Mon, 26 Feb 2001 06:57:38 -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 f1QEva607692
	for <freebsd-hackers@freebsd.org>; Mon, 26 Feb 2001 08:57:36 -0600 (CST)
Message-Id: <200102261457.f1QEva607692@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 "Sun, 25 Feb 2001 22:06:18 PST."
             <3A99F25A.B940BEE0@elischer.org> 
Date: Mon, 26 Feb 2001 08:57:35 -0600
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <3A99F25A.B940BEE0@elischer.org>, Julian Elischer writes:
>I still think that in such a case it should be possible to
>'test the commitment' by touching all the allocated memory 
>while trapping page faults.

And what do you do if you get one?  There's no undo button for SIGSEGV.
Traditionally, you return from the signal handler right where you were.
Can you get out of this with longjmp()?  Probably.  It's not exactly
supported or guaranteed.

In any event:

1.  The C language spec doesn't require you to do this.
2.  Other implementations have provided this guarantee, at least as an
option.

It's odd that I see lots of people arguing for segfaults killing the process
accessing memory that has been "successfully" allocated, but no one arguing
for the process getting killed when it exceeds a disk quota.

-s

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message