🚀 go-pugleaf

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.