Shrinking with realloc

[Steve Summit]

In article <10711 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
>In article <26362 at shemp.CS.UCLA.EDU> signup at 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 at adam.pika.mit.edu

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