C Language, Stability of realloc

Stability of realloc

Author	Message
Joona I Palast #1 / 25	Stability of realloc Quote: > I've heard stories from some of my fellow students about funky things > happening due to realloc(). My question - are there known issues, or was my > friend simply missing a bug in his own code? If there are any "known issues", they are with the student's own implementation of C. realloc() itself is simply a specification for a function. But there is one thing to take note of when using realloc(). You generally don't want to do this: char p = malloc(SIZE); p = realloc(p, BIGGER_SIZE); If the realloc() call is unable to increase the size, the second line will set p to NULL, causing SIZE bytes of memory to become unavailable. The correct way to do this is something like this: char p = malloc(SIZE); char temp_p; if (temp_p=realloc(p, BIGGER_SIZE) p=temp_p; -- \| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++\| \| http://www.--.com/ ~palaste W++ B OP+ \| \----------------------------------------- Finland rules! ------------/ "Bad things only happen to scoundrels." - Moominmamma
Tue, 09 Aug 2005 02:10:43 GMT

Christopher Benson-Manic #2 / 25	Stability of realloc I've heard stories from some of my fellow students about funky things happening due to realloc(). My question - are there known issues, or was my friend simply missing a bug in his own code? -- Christopher Benson-Manica \| You have a right to think for yourself. CS 1321 TA \| You are controlled because you want to be. \| Take a stand on something www.adbusters.org/home \| Why stand on a silent platform? www.stayfreemagazine.org \| Smash the State, Fight Back.
Tue, 09 Aug 2005 01:55:53 GMT

Ben Pfaf #3 / 25	Stability of realloc Quote: > I've heard stories from some of my fellow students about funky things > happening due to realloc(). My question - are there known issues, or was my > friend simply missing a bug in his own code? Besides Joona's suggestion, it is easy to{filter}up with realloc() if you have pointers into a block and then reallocate it. You need to be prepared to change all pointers into an existing block to point into the new one. -- "C has its problems, but a language designed from scratch would have some too, and we know C's problems." --Bjarne Stroustrup
Tue, 09 Aug 2005 02:14:06 GMT

Christian Ba #4 / 25	Stability of realloc Quote: > > I've heard stories from some of my fellow students about funky things > > happening due to realloc(). My question - are there known issues, or was my > > friend simply missing a bug in his own code? > If there are any "known issues", they are with the student's own > implementation of C. realloc() itself is simply a specification for a > function. > But there is one thing to take note of when using realloc(). You > generally don't want to do this: > char p = malloc(SIZE); > p = realloc(p, BIGGER_SIZE); > If the realloc() call is unable to increase the size, Note that there is absolutely no guarantee that realloc () will be successful if you decrease the size or pass in the original size. Quote: > the second line > will set p to NULL, causing SIZE bytes of memory to become unavailable. > The correct way to do this is something like this: > char p = malloc(SIZE); > char *temp_p; > if (temp_p=realloc(p, BIGGER_SIZE) > p=temp_p;
Tue, 09 Aug 2005 06:11:49 GMT

Tony Finc #5 / 25	Stability of realloc Quote: >If there are any "known issues", they are with the student's own >implementation of C. realloc() itself is simply a specification for a >function. It's an amusing exercise to dig back to 15 years ago and see quite how bad the specification for realloc() was before ANSI. It's still not without problems. Tony. -- MULL OF KINTYRE TO ARDNAMURCHAN POINT: SOUTHEAST 3 OR 4 VEERING SOUTHEAST TO SOUTH 4 OR 5, LATER INCREASING 6 OR 7. DRY, FAIR EARLY. BECOMING CLOUDY, PERIOD RAIN, INTERMITTENT LATER. GOOD FALLING MODERATE IN RAIN. SLIGHT TO MODERATE GRADUALLY INCREASING ROUGH.
Tue, 09 Aug 2005 08:19:21 GMT

Jens.Toerr.. #6 / 25	Stability of realloc Quote: >>If there are any "known issues", they are with the student's own >>implementation of C. realloc() itself is simply a specification for a >>function. > It's an amusing exercise to dig back to 15 years ago and see quite how > bad the specification for realloc() was before ANSI. It's still not > without problems. What do you mean with "It's still not without problems."? Are you talking about what the standard says about it or about some implementation? I am just curious because I have used realloc() for years on different machines and with different compilers and can't remember to have experienced any problems - and the standard seems to leave not much leeway in interpreting how it is supposed to work. Regards, Jens -- _ _____ _____ _ \| \| \| \| \| \| \| \|_\| \| \| \| \| \| http://www.physik.fu-berlin.de/~toerring \___/ens\|_\|homs\|_\|oerring
Tue, 09 Aug 2005 10:03:59 GMT

those who know me have no need of my nam #7 / 25	Stability of realloc in comp.lang.c i read: Quote: >I've heard stories from some of my fellow students about funky things >happening due to realloc(). My question - are there known issues, or was my >friend simply missing a bug in his own code? in addition to the responses you've had so far, i've seen people use realloc under the presumption that it will always change the size of the pointer `in place', so they call it simply: realloc(p, size); ignoring the return value completely. all too often students seem to do this, likely because they have been shown examples that eschew the return value in favor of clarity of the program logic, which has it's place. but in a teaching environment it should be accompanied by a real example, complete with return value inspection, and error checking and handling, such as the examples that have been provided in other articles. this is wrong for a second reason. c is a pass by value language, each parameter is copied to a parameter storage location (often a stack) before the function is called -- any changes made are to the copy, so the parent's variable remains unaffected. if the caller's variable is to be changed by the function a pointer to it must be passed, that value is the address of the caller's variable so providing the function what is necessary. i.e., realloc would have to have a signature of: void * realloc(void ** object, size_t newsize); and would have to be called as: realloc(&p, size); note: realloc does not have this signature, it's an example only. do not attempt to call it as i've shown. -- bringing you boring signatures for 17 years
Tue, 09 Aug 2005 12:39:15 GMT

Christian Ba #8 / 25	Stability of realloc Quote: > >If there are any "known issues", they are with the student's own > >implementation of C. realloc() itself is simply a specification for a > >function. > It's an amusing exercise to dig back to 15 years ago and see quite how > bad the specification for realloc() was before ANSI. It's still not > without problems. The first time I read a specification of realloc () the author wrote that realloc () returns NULL if reallocation is not successful. He forgot to mention that in that case, the original data is still tucked away safely in the original pointer :(
Tue, 09 Aug 2005 15:41:45 GMT

Dan P #9 / 25	Stability of realloc Quote: >>>If there are any "known issues", they are with the student's own >>>implementation of C. realloc() itself is simply a specification for a >>>function. >> It's an amusing exercise to dig back to 15 years ago and see quite how >> bad the specification for realloc() was before ANSI. It's still not >> without problems. >What do you mean with "It's still not without problems."? Are you >talking about what the standard says about it or about some >implementation? I am just curious because I have used realloc() >for years on different machines and with different compilers and >can't remember to have experienced any problems - and the standard >seems to leave not much leeway in interpreting how it is supposed >to work. He's probably referring to the fact that the behaviour is not well defined if the new size is zero. You can get back either a null pointer or a pointer that is different from any other valid pointer. Dan -- Dan Pop DESY Zeuthen, RZ group
Tue, 09 Aug 2005 20:14:11 GMT

Bruce #10 / 25	Stability of realloc Quote: writes: > >>>If there are any "known issues", they are with the student's own > >>>implementation of C. realloc() itself is simply a specification for a > >>>function. > >> It's an amusing exercise to dig back to 15 years ago and see quite how > >> bad the specification for realloc() was before ANSI. It's still not > >> without problems. > >What do you mean with "It's still not without problems."? Are you > >talking about what the standard says about it or about some > >implementation? I am just curious because I have used realloc() > >for years on different machines and with different compilers and > >can't remember to have experienced any problems - and the standard > >seems to leave not much leeway in interpreting how it is supposed > >to work. > He's probably referring to the fact that the behaviour is not well > defined if the new size is zero. You can get back either a null pointer > or a pointer that is different from any other valid pointer. I recall (years ago) reading a manual entry that claimed realloc(p, 0) would do the equivalent of free(p) and return NULL. _Writing Solid Code_ confirms this, as does a "man realloc" under cygwin, and probably many other sources. However, when I asked about it on clc, I was informed that this was not guaranteed by the Standard, and now that I have the Standard, I see that specifically listed under Annex J, section J.1 "Unspecified behavior", and elsewhere. "How many times must a manual err, Before you stop using that man? The answer my friend is ISO/IEC 9899:1999"
Wed, 10 Aug 2005 01:42:00 GMT

Ben Pfaf #11 / 25	Stability of realloc Quote: > I recall (years ago) reading a manual entry that claimed realloc(p, 0) would > do the equivalent of free(p) and return NULL. _Writing Solid Code_ confirms > this, as does a "man realloc" under cygwin, and probably many other sources. > However, when I asked about it on clc, I was informed that this was not > guaranteed by the Standard, and now that I have the Standard, I see that > specifically listed under Annex J, section J.1 "Unspecified behavior", and > elsewhere. You are confusing two different cases: * realloc(block, 0): This behaves like free(block). (The return value is uninteresting.) * realloc(NULL, size): This behaves like malloc(size). realloc(NULL, 0) is a special case of the latter. -- "The way I see it, an intelligent person who disagrees with me is probably the most important person I'll interact with on any given day." --Billy Chambless
Wed, 10 Aug 2005 03:46:54 GMT

Bruce #12 / 25	Stability of realloc Quote: > > I recall (years ago) reading a manual entry that claimed realloc(p, 0) would > > do the equivalent of free(p) and return NULL. _Writing Solid Code_ confirms > > this, as does a "man realloc" under cygwin, and probably many other sources. > > However, when I asked about it on clc, I was informed that this was not > > guaranteed by the Standard, and now that I have the Standard, I see that > > specifically listed under Annex J, section J.1 "Unspecified behavior", and > > elsewhere. > You are confusing two different cases: > * realloc(block, 0): This behaves like free(block). (The > return value is uninteresting.) This is the case I'm referring to. I would characterize the return value as unsafe, and it appears that it isn't necessarily equivalent to free even with that caveat. The Standard says, among other things: J1.1 Unspecified behavior "- The amount of storage allocated by a successful call to the calloc, malloc,or realloc function when 0 bytes was requested (7.20.3)." J3.12 Implementation-defined behavior: Libray functions "- Whether the calloc, malloc, and realloc functions return a null pointer or a pointer to an allocated object when the size requested is zero (7.20.3)." IOW, despite what some sources indicate, it isn't safe to do somePtr = realloc(somePtr, 0); rather than free(somePtr); somePtr = NULL; It isn't even safe to assume that realloc(somePtr, 0); is equivalent to free(somePtr); I suspect that, in most cases, it is safe, but not being defined so by the Standard, it isn't portably so. Am I mising something? It wouldn't be the first time, but the Standard seems to back me up here. Quote: > * realloc(NULL, size): This behaves like malloc(size). This much seems well defined under 7.20.3. No argument here. - Hide quoted text - - Show quoted text - Quote: > realloc(NULL, 0) is a special case of the latter. > -- > "The way I see it, an intelligent person who disagrees with me is > probably the most important person I'll interact with on any given > day." > --Billy Chambless
Wed, 10 Aug 2005 04:49:21 GMT

Ben Pfaf #13 / 25	Stability of realloc Quote: > > * realloc(block, 0): This behaves like free(block). (The > > return value is uninteresting.) > This is the case I'm referring to. I would characterize the return value as > unsafe, and it appears that it isn't necessarily equivalent to free even > with that caveat. The Standard says, among other things: > J1.1 Unspecified behavior > "- The amount of storage allocated by a successful call to the calloc, > malloc,or > realloc function when 0 bytes was requested (7.20.3)." It's not unsafe, it's just that it might allocate a 0-byte block, just like malloc(0). That would be an unwise implementation choice, though. Quote: > J3.12 Implementation-defined behavior: Libray functions > "- Whether the calloc, malloc, and realloc functions return a null pointer > or a > pointer to an allocated object when the size requested is zero (7.20.3)." > IOW, despite what some sources indicate, it isn't safe to do > somePtr = realloc(somePtr, 0); It'll free your block--read the definition of realloc(). Just don't depend on it returning a null pointer. Quote: > rather than > free(somePtr); > somePtr = NULL; > It isn't even safe to assume that > realloc(somePtr, 0); > is equivalent to > free(somePtr); Yes it is. Quote: > I suspect that, in most cases, it is safe, but not being defined so by the > Standard, it isn't portably so. Am I mising something? It wouldn't be the > first time, but the Standard seems to back me up here. realloc(pointer, 0) will free your block. Whether it returns a null pointer or a 0-size block is up to the implementation, and you can't depend on it. -- "Given that computing power increases exponentially with time, algorithms with exponential or better O-notations are actually linear with a large constant." --Mike Lee
Wed, 10 Aug 2005 04:53:41 GMT

CBFalcone #14 / 25	Stability of realloc Quote: ... snip ... > I recall (years ago) reading a manual entry that claimed > realloc(p, 0) would do the equivalent of free(p) and return NULL. >_Writing Solid Code_ confirms this, as does a "man realloc" under > cygwin, and probably many other sources. However, when I asked > about it on clc, I was informed that this was not guaranteed by > the Standard, and now that I have the Standard, I see that > specifically listed under Annex J, section J.1 "Unspecified > behavior", and elsewhere. > "How many times must a manual err, > Before you stop using that man? > The answer my friend is ISO/IEC 9899:1999" My nmalloc implementation for djgpp would, assuming p is a valid malloc'd pointer, return p for this call. Not specified, but compliant. If p is invalid it will emit a message to stderr and signal. Again, not specified, but compliant. -- Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
Wed, 10 Aug 2005 07:21:11 GMT

CBFalcone #15 / 25	Stability of realloc Quote: ... snip ... > You are confusing two different cases: > * realloc(block, 0): This behaves like free(block). (The > return value is uninteresting.) Unless the standard is seriously changed from N869, this is not _required_. If it has been changed I want to know about it :-). -- Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
Wed, 10 Aug 2005 07:21:13 GMT

Page 1 of 2

[ 25 post ]

Go to page: [1] [2]