Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!ulysses!kpv
From: kpv@ulysses.homer.nj.att.com (Phong Vo[drew])
Newsgroups: comp.lang.c
Subject: Re: malloc's and signals -- a dangerous mixture?
Summary: robust malloc
Keywords: C,UNIX,malloc,signal
Message-ID: <11779@ulysses.homer.nj.att.com>
Date: 11 Jul 89 13:41:16 GMT
References: <1064@dinl.mmc.UUCP> <12571@bloom-beacon.MIT.EDU>
Distribution: na
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 14

In article <12571@bloom-beacon.MIT.EDU>, scs@adam.pika.mit.edu (Steve Summit) writes:
> Many people have researched better malloc implementations,
> usually for speed or better space utilization.  Has anyone ever
> tried to make a more robust implementation (this is essentially a

Robust malloc sounds like a good example of an oxymoron.
My one great contribution to fault-tolerant computing that may help
some programs to limp a little longer
is to always double the size of the malloc request.
Quiz: what famous UNIX os provides a malloc with almost that feature:-)?
On a more serious vein, there are simple ways to add trace
information to malloc space and periodically check to see if
the arena has been corrupted. Doing this, of course, will make
the program runs slooooow.