From owner-freebsd-hackers Sat Feb 24 8:44: 4 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 185DA37B491 for ; Sat, 24 Feb 2001 08:44:00 -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 f1OGhw616627 for ; Sat, 24 Feb 2001 10:43:59 -0600 (CST) Message-Id: <200102241643.f1OGhw616627@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 "24 Feb 2001 16:40:33 +0100." Date: Sat, 24 Feb 2001 10:43:58 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Dag-Erling Smorgrav writes: >This is all academic since FreeBSD does memory overcommit, so unless >you run out of address space for your process before you run out of >actual memory and/or swap (not likely, but quite possible) malloc() >will never return NULL and you won't know a thing until you dirty one >page too many and segfault. Is there any hope that, some day, a setting could be provided where a program could request that malloc *NOT* overcommit? There are programs which would rather know in advance, and clean up, than be killed abruptly. (To be pedantic, this is a conformance issue. If the memory isn't actually allocated, malloc shouldn't be returning a non-null pointer.) -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message