Xref: utzoo comp.std.c:940 comp.lang.c:17259
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: realloc
Keywords: realloc NULL
Message-ID: <9941@smoke.BRL.MIL>
Date: 29 Mar 89 15:48:43 GMT
References: <10170@bloom-beacon.MIT.EDU>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 18

In article <10170@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes:
>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.

While that's required for ANSI C standard conformance, in fact
many existing C implementations do not behave that way, and it
isn't advertised behavior even in the current UNIX release (I
don't think it even works that way).  Therefore it is unwise to
rely on this behavior in an application intended for a
not-necessarily-ANSI-conforming environment.

So why standardize this uncommon behavior?  I think the intent
was to make programming easier at some future date when nearly
all C environments will be standard conforming.