🚀 go-pugleaf

In article <1431@cbnewsl.ATT.COM> dfp@cbnewsl.ATT.COM (david.f.prosser) writes:
>In article <26328@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?