signup@valhalla.cs.ucla.edu (08/10/89)
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. I.e., after char *p, *q; q = p = (char *) malloc(10); (void) realloc(p,5); is it valid to dereference q?
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/10/89)
In article <26328@shemp.CS.UCLA.EDU> signup@CS.UCLA.EDU writes: >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.
dfp@cbnewsl.ATT.COM (david.f.prosser) (08/10/89)
In article <26328@shemp.CS.UCLA.EDU> signup@CS.UCLA.EDU writes: >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. > >I.e., after > char *p, *q; > q = p = (char *) malloc(10); > (void) realloc(p,5); >is it valid to dereference q? 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...
signup@valhalla.cs.ucla.edu (Undergraduate CS Course Signups) (08/11/89)
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?
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (08/11/89)
In article <10698@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <26328@shemp.CS.UCLA.EDU> signup@CS.UCLA.EDU writes: >>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. 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: jfh@rpp386.cactus.org | reincarnated Space Food Sticks." UUCPNet: {texbell|bigtex}!rpp386!jfh +------------ -- Richard Sexton ---
dfp@cbnewsl.ATT.COM (david.f.prosser) (08/11/89)
In article <26362@shemp.CS.UCLA.EDU> signup@cs.ucla.edu writes: >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? 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...
pardo@june.cs.washington.edu (David Keppel) (08/12/89)
In article <26362@shemp.CS.UCLA.EDU> signup@cs.ucla.edu writes: >[Realloc used 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? 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 -- pardo@cs.washington.edu {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
bright@Data-IO.COM (Walter Bright) (08/12/89)
In article <26362@shemp.CS.UCLA.EDU> signup@cs.ucla.edu writes:
<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.
<It seems easy to provide; was it ever considered?
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.gwyn@smoke.BRL.MIL (Doug Gwyn) (08/12/89)
In article <26362@shemp.CS.UCLA.EDU> signup@cs.ucla.edu writes: >[no_move_realloc] seems easy to provide; was it ever considered? 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..
scs@adam.pika.mit.edu (Steve Summit) (08/13/89)
In article <10711@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <26362@shemp.CS.UCLA.EDU> signup@cs.ucla.edu writes: >>[no_move_realloc] seems easy to provide; was it ever considered? >No... This is the first time I've ever even >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 scs@adam.pika.mit.edu P.S. Yes, I know that realloc might return NULL if realsize is 0.
henry@utzoo.uucp (Henry Spencer) (08/13/89)
In article <2090@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes: >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 henry@zoo.toronto.edu