Shrinking with realloc

[david.f.prosser]

In article <26362 at shemp.CS.UCLA.EDU> signup at cs.ucla.edu writes:
 >In article <1431 at cbnewsl.ATT.COM> dfp at cbnewsl.ATT.COM (david.f.prosser) writes:
 >>In article <26328 at 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.
 >>
 >>... no ... Having such a requirement on realloc would overly constrain
 >>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?

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.

Dave Prosser	...not an official X3J11 answer...