Xref: utzoo comp.std.c:943 comp.lang.c:17261
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!rutgers!att!ihlpb!gregg
From: gregg@ihlpb.ATT.COM (Wonderly)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: realloc
Message-ID: <10032@ihlpb.ATT.COM>
Date: 29 Mar 89 15:24:38 GMT
References: <10170@bloom-beacon.MIT.EDU>
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 27

From article <10170@bloom-beacon.MIT.EDU>, by scs@adam.pika.mit.edu (Steve Summit):
> Today, for the third time in half as many years, I got badly
> burned, and wasted lots of time, due to a bug in a certain
> vendor's implementation of realloc.  It is an apparently well-
> kept secret that realloc is supposed to behave gracefully at
> a slightly special-cased boundary point: when handed a NULL
> pointer and a nonzero size, it acts essentially as a malloc.

I read the man page for realloc and it said nothing about this.  Is it
not possible for you to type

	if (ptr == NULL)
		ptr = malloc (nbytes);
	else
		ptr = realloc (ptr, nbytes);

or are you one of those people that assumes (*((char *)NULL) == 0) too?
This damn lazy programming and sorry excuses for not being defensive has
got to stop.  Hiding all of the magic in the inards of the implementation
does not make it any easier for people to understand the code!  I have
never assumed that realloc() would accept a NULL pointer and if I ever
saw the type of coding that you talk about I would instantly say BUG.
Its like seeing "malloc (strlen (s));".  I know it is W-R-O-N-G!

-- 
Gregg Wonderly                             DOMAIN: gregg@ihlpb.att.com
AT&T Bell Laboratories                     UUCP:   att!ihlpb!gregg