Xref: utzoo comp.std.c:953 comp.lang.c:17285
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!ai-lab!jym
From: jym@wheaties.ai.mit.edu (Jym Dyer)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: realloc
Message-ID: <1360@corn-chex.ai.mit.edu>
Date: 29 Mar 89 19:48:35 GMT
References: <10170@bloom-beacon.MIT.EDU> <10032@ihlpb.ATT.COM>
Reply-To: jym@wheaties.ai.mit.edu (Jym Dyer)
Organization: Project GNU, Free Software Foundation
Lines: 27

In article <10032@ihlpb.ATT.COM> gregg@ihlpb.ATT.COM (Wonderly) writes:
> From article <10170@bloom-beacon.MIT.EDU>, by scs@adam.pika.mit.edu (Steve Summit):
>> 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.

Actually, that's a new innovation.  A good one, though.

> Is it not possible for you to type
>
>	if (ptr == NULL)
>		ptr = malloc (nbytes);
>	else
>		ptr = realloc (ptr, nbytes);

Possible, but not desirable.  If you're going to have to use this if/else
 statement every time you use realloc(), you might as well put it into
  realloc().  And that's why ANSI-conforming realloc()s do just that.

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

I saw no such assumption, no "damn lazy programming" and no "sorry excuses
 for not being defensive."  Steve Summit's article was, in fact, quite
  helpful.
   <_Jym_>