On 9/4/07, Douglas A. Gwyn <DAGwyn@null.net> wrote:
>> malloc just moves the brk, but the backing pages don't get
>> allocated until the pages are accessed (during memset).

"erik quanstrom" <quanstro@quanstro.net > wrote in message
news:d7c705e9c3355e723c8f69677bf2d851@quanstro.net...

> i'm just suprised that plan 9 overcommits.  this makes
> this code nonsensical from user space
> if((p = malloc(Size)) == 0)

Indeed, when I discovered that Linux was overcommitting memory
in much the same way, which in my view is erroneous design, I
added an optional feature to my portable malloc implementation
that (on systems neeing it) would touch every allocated page
before reporting success.  (During the touch loop a trap catcher
would set a flag that would be tested after the loop to determine
whether there had ben any faults.)  malloc really shouldn't have
to do this, but if you're insisting on overcommitment in the OS
then the library malloc() needs to do it.  Otherwise, applications
that try to be careful may still fail "randomly", which is intolerable.

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 :-).

The problem there, in my opinion, was not the OS's behavior, but the inexperience of the coder in question with realloc.  The terrible side effect of all these garbage collected languages or ones that don't make you manage memory much is that programmers have this attitude that they aren't to blame when their code has flaws.

Mac OS X has many options for testing malloc results as well.  It can scribble on pages etc... I'm sure glibc has these options somewhere too.  They're great testing tools.

Dave