Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.std.c
Subject: Re: realloc
Message-ID: <1991Apr23.045937.178@Think.COM>
Date: 23 Apr 91 04:59:37 GMT
References: <91112.102011LSC@SLACVM.SLAC.STANFORD.EDU> <1991Apr23.001451.14900@tkou02.enet.dec.com>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 26

In article <1991Apr23.001451.14900@tkou02.enet.dec.com> diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond) writes:
>In article <91112.102011LSC@SLACVM.SLAC.STANFORD.EDU> LSC@SLACVM.SLAC.STANFORD.EDU writes:
>>     "If the space cannot be allocated, the object pointed to by ptr is unchang
>>unchanged."
>Failure is still indicated by returning a null pointer as the function's
>returned value.

What this *does* mean is that the common practice of

	fooptr = realloc (fooptr, newsize);

results in a memory leak whenever realloc() returns a null pointer.  Of
course, when realloc() fails, it's probably because you're out of memory,
so this one unfreeable allocation probably isn't a problem.  However, the
point is that one *should* write

	new_fooptr = realloc (fooptr, newsize);
	if (new_fooptr) {
	    fooptr = new_fooptr;
	}
	else /* report the error */
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar