From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3e1162e60709040854p309a7ca4p9d74ea6af38af025@mail.gmail.com> Date: Tue, 4 Sep 2007 08:54:22 -0700 From: "David Leimbach" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] plan 9 overcommits memory? In-Reply-To: <2ba96fc2203d0c710f6da96b72127752@coraid.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18329_20242778.1188921262512" References: <3e1162e60709040639u39e8ee90o42e71103aa1ce2ab@mail.gmail.com> <2ba96fc2203d0c710f6da96b72127752@coraid.com> Topicbox-Message-UUID: b7ac6cae-ead2-11e9-9d60-3106f5b1d025 ------=_Part_18329_20242778.1188921262512 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 9/4/07, erik quanstrom wrote: > > On Tue Sep 4 09:39:37 EDT 2007, leimy2k@gmail.com wrote: > > > Yep, I've seen code with totally erroneous use of realloc work perfectly > on > > Linux for example, due to it's behavior. Then I built it on FreeBSD and > it > > failed appropriately :-). > > what does this have to do with memory overcommitment? k&r second ed, > p. 252 specifies that malloc and realloc return NULL if the request can't > be specified. > > - erik > Plenty if I shared the code with you... :-) Has to do with what memory was allocated vs what was being used. Unfortunately I'm not at liberty to post such code. Let's just say it shouldn't have returned NULL in this case (to my recollection). Different OSes behave differently with what is committed via the allocation functions of stdlib. I'm thinking they're creeping into undefined behavior territory of the standard rather than modes that are explicitly supposed to fail. Dave ------=_Part_18329_20242778.1188921262512 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 9/4/07, erik quanstrom <quanstro@coraid.com> wrote:
On Tue Sep  4 09:39:37 EDT 2007, leimy2k@gmail.com wrote:

> Yep, I've seen code with totally erroneous use of realloc work perfectly on
> Linux for example, due to it's behavior.  Then I built it on FreeBSD and it
> failed appropriately :-).

what does this have to do with memory overcommitment?  k&r second ed,
p. 252 specifies that malloc and realloc return NULL if the request can't
be specified.

- erik

Plenty if I shared the code with you... :-)  Has to do with what memory was allocated vs what was being used. 

Unfortunately I'm not at liberty to post such code.

 
Let's just say it shouldn't have returned NULL in this case (to my recollection).  Different OSes behave differently with what is committed via the allocation functions of stdlib.  I'm thinking they're creeping into undefined behavior territory of the standard rather than modes that are explicitly supposed to fail.

Dave
------=_Part_18329_20242778.1188921262512--