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?