Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdahl!uunet!cs.dal.ca!iotek!mike
From: mike@iotek.UUCP (Mike Thompson)
Newsgroups: comp.sys.sgi
Subject: Re: -lmalloc
Message-ID: <295@jupiter.iotek.UUCP>
Date: 1 Feb 89 14:06:42 GMT
References: <4143@pt.cs.cmu.edu> <3724@ingr.com>
Reply-To: mike@jupiter.UUCP (Mike Thompson)
Organization: IOTEK Inc
Lines: 29

In article <3724@ingr.com> dan@ingr.com (Dan Webb) writes in reply to 
	article <4143@pt.cs.cmu.edu>, scotts@isl1.ri.cmu.edu (Scott Safier):
>I've had the same problem with -lmalloc (also known as malloc(3X)).
>The crashes are probably caused by the fact that this implementation of
>malloc, for some reason, treats a request for zero bytes as invalid.
>It therefore returns a NULL pointer, which is probably passed to free()
>or realloc() later, resulting in a core dump.
>
>I probably don't have to convince too many people of this, but a request
>for zero bytes is by no means an invalid request.  I think -lmalloc should
>be fixed.
>
>	 - Dan Webb

	Well I'm one of those few who need convincing, I think that
    treating a request for 0 memory from a memory managment system as
    an error is if not correct is at least not incorrect, to give you
    a valid pointer would in effect be allocating at least a byte,
    after all that address cannot be allocated to any other request
    can it?  On the other hand a program that does not check for
    errors on system calls, and does no checking for null pointers is
    definitely what I would call not written in the best of styles if
    not down right buggy!  (especially with the problems of null
    de-referencing effecting portability over the past few years)
-- 
<<<<<<******>>>>>>
Michael A. Thompson, Iotek Inc, |*| E-Mail: mike@iotek.uucp	|*| Have
1127 Barrington St., Suite 100, |*| Fax:    (902)420-0674	|*|   a Good
Halifax, N.S., B3H 2P8, Canada  |*| Phone:  (902)420-1890	|*|     Day :-)