Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!cica!ctrsol!sdsu!usc!elroy.jpl.nasa.gov!ucla-cs!signup
From: signup@valhalla.cs.ucla.edu (Undergraduate CS Course Signups)
Newsgroups: comp.std.c
Subject: Re: Shrinking with realloc
Message-ID: <26362@shemp.CS.UCLA.EDU>
Date: 10 Aug 89 22:15:06 GMT
References: <26328@shemp.CS.UCLA.EDU> <1431@cbnewsl.ATT.COM>
Sender: news@CS.UCLA.EDU
Reply-To: signup@cs.ucla.edu
Organization: UCLA Computer Science
Lines: 16

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?