Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!rjf001!hpftc!teemc!rphroy!edsews!uunet!tut.cis.ohio-state.edu!bloom-beacon!adam.pika.mit.edu!scs
From: scs@adam.pika.mit.edu (Steve Summit)
Newsgroups: comp.std.c
Subject: Re: Shrinking with realloc
Message-ID: <13444@bloom-beacon.MIT.EDU>
Date: 12 Aug 89 19:58:00 GMT
References: <26328@shemp.CS.UCLA.EDU> <1431@cbnewsl.ATT.COM> <26362@shemp.CS.UCLA.EDU> <10711@smoke.BRL.MIL>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 29

In article <10711@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <26362@shemp.CS.UCLA.EDU> signup@cs.ucla.edu writes:
>>[no_move_realloc] seems easy to provide; was it ever considered?
>No...  This is the first time I've ever even
>heard a complaint about this facet of realloc()'s (existing) design.

On a related note, how indefensible is it to neglect to check for
an error return from a realloc call which shrinks the region?
I'm as paranoid as the next guy about always checking for error
returns, even in "can't happen" situations, but in a moment of
weakness I once wrote something like

	return realloc(buf, realsize);

as the last line of a routine that had been dynamically growing a
buffer to be as big as (or bigger than) it needed to be.  Deep in
the heartland, paranoia might strike one to write

	if((shrunken = realloc(buf, realsize)) == NULL)
		return buf;	/* oh well, can't shrink */
	else	return shrunken;

but this wastes code and a temporary variable and seems unnecessary
since failure in this case _really_ can't happen, right?

                                            Steve Summit
                                            scs@adam.pika.mit.edu

P.S. Yes, I know that realloc might return NULL if realsize is 0.