Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!epiwrl!wrl.epi.com!nelson
From: nelson@wrl.epi.com (Ken Nelson)
Newsgroups: comp.lang.c
Subject: Re: Why use -lmalloc
Message-ID: <869@epiwrl.UUCP>
Date: 3 Apr 91 17:02:44 GMT
References: <2@bodedo.UUCP> <179@atesysv.UUCP>
Sender: news@epiwrl.UUCP
Reply-To: nelson@wrl.epi.com (Ken Nelson)
Organization: Entropic Research Laboratory, Washington D.C.
Lines: 34


 We just ported our product to HP-UX and could not get it
 to work with the normal allocation routines.  In fact
 we couldn't get it to work with -lmalloc as well.  BUT
 when we used -lmalloc we got error messages out that made
 sense (other than core dump) and we were able to fix the
 problem.

 -lmalloc offered diagnostic warnings that normal
  alloc didn't.  It notified us when the program
  tried to allocate a block of space of size 0.  The
  normal alloc just returned a bad address that we
  used until we corrupted something and the program
  died far away from the bad code.


Of course we could have prevented this by putting a wrapper
around any call to malloc that checked for valid requests and
valid answers. Normally we do, but this code was inherited from
another company (Sun Microsystems XView library).  By the way
the request for zero space works okay on every other system
we have ported XView to (Sun3, Sun4, Dec, Concurrent, Apollo,
Convex, and more).

So this isn't just a testimonial for -lmalloc, but a call
for more defensive programming.


 --------------------------------------------------------------------
| Ken Nelson  (nelson@wrl.epi.com) | No thoughts today, sorry.	     | 
| Computer Systems Manager         |				     |
| Entropic Research Laboratory     |				     |	
| Washington, D.C.		   |				     |
|--------------------------------------------------------------------