Shrinking with realloc
sig...@valhalla.cs.ucla.edu
by the standard that the storage won't be moved? I couldn't find any positive
or negative statement about the matter.
I.e., after
char *p, *q;
q = p = (char *) malloc(10);
(void) realloc(p,5);
is it valid to dereference q?
Doug Gwyn
>If realloc is used to shrink a chunk of allocated storage, is it guaranteed
>by the standard that the storage won't be moved?
No, the storage is always potentially subject to being moved by realloc(),
perhaps as part of the malloc package's grand allocation scheme.
david.f.prosser
Short answer: "no".
Long answer: Having such a requirement on realloc would overly constrain
its implementation, quite possibly causing wasted memory. This is because
the fancier malloc/realloc/free implementations have special pools for
certain sized (typically small) blocks, and crossing such a size boundary
would necessitate copying the data. Also, copying of a small amount of
data is not too costly when the overall space usage "wins".
Dave Prosser ...not an official X3J11 answer...
Undergraduate CS Course Signups
>In article <26...@shemp.CS.UCLA.EDU> I ask:
>>If realloc is used to shrink a chunk of allocated storage, is it guaranteed
>>by the standard that the storage won't be moved? I couldn't find any positive
>>or negative statement about the matter.
>
>its implementation, quite possibly causing wasted memory.
Hmmm... then I can't use realloc if I have arbitrarily-located pointers into
the allocated chunk whose values I want to remain valid, even if I'm
shrinking the chunk. I guess what I'd want is a no_move_realloc that returns
NULL if it can't do the realloc in place, leaving the area allocated.
no_move_realloc would be like a hint to the storage allocator, saying in a
shrinking context "Here's some space you can have back if you want; no biggie
if you can't use it." It seems easy to provide; was it ever considered?
John F. Haugh II
Perhaps also because the headers required for each block may be larger
than the amount of free space returned.
It is not generally true that the space being returned can be tacked
on to some larger region leaving the remainder alone.
--
John F. Haugh II +-Quote of the month club: ------------
VoiceNet: (512) 832-8832 Data: -8835 | "Chocolate Teddy Grahams are just
InterNet: j...@rpp386.cactus.org | reincarnated Space Food Sticks."
UUCPNet: {texbell|bigtex}!rpp386!jfh +------------ -- Richard Sexton ---
david.f.prosser
As best as I can recall, such a function was never proposed to be part of the
standard library. You are correct that it should be simple to implement for
most of the existing memory allocation schemes, but does it address a "real
need"? Since a program can put its own memory allocation layer between its
heap usage and malloc/realloc/free, it's pretty easy to see how to provide
the desired effect in the program's interface to realloc.
David Keppel
>shrinking context "Here's some space you can have back if you want; no biggie
>if you can't use it." It seems easy to provide; was it ever considered?
Doubtless it has been considered over and over. The charter of the
ANSI committee is to codify existing standard practice. If you think
it belongs in the next version of ANSI C, then implement it and
submit it as `prior art'.
Followups to comp.lang.c.
;-D on ( The standard answer ) Pardo
--
pa...@cs.washington.edu
{rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
Walter Bright
<NULL if it can't do the realloc in place, leaving the area allocated.
Easy to provide is not the only criterion. Adding a function to the library
involves:
1. Usefulness of the function.
2. Difficulty of implementation.
3. Impact on size and weight of manual.
4. Desirability for backwards compatibility.
5. Impact on size of provided libraries.
Lots of functions are easy to implement, but don't get implemented because
the utility is small. There are an infinite number of these, and stuffing
pages in the manual for all of them makes it hard to find the useful ones.
The C library is already very large. Adding functions shouldn't be done
unless there is a demonstrable significant need.
If it's easy to implement, why don't you simply write it and put it in
your personal version of the library? Most vendors supply library source
for this purpose.
Doug Gwyn
No, and it is unlikely that it would have been included in the Standard
even if it had been proposed. This is the first time I've ever even
heard a complaint about this facet of realloc()'s (existing) design.
It doesn't seem like a significant deficiency in existing practice..
Steve Summit
>>[no_move_realloc] seems easy to provide; was it ever considered?
>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
s...@adam.pika.mit.edu
P.S. Yes, I know that realloc might return NULL if realsize is 0.
Henry Spencer
>The C library is already very large...
Actually not true; it is disgracefully small, which leads to repeated
re-invention of the wheel. See my paper "How To Steal Code" in the
San Francisco Usenix proceedings for a dozen examples.
>... Adding functions shouldn't be done
>unless there is a demonstrable significant need.
This, however, is definitely true.
--
V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology
1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu