Stability of realloc 
Author Message
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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.

- 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  
 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  
 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  
 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  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. malloc()/realloc() vs realloc()

2. Realloc failure when downsizing (was Re: Probably a simple realloc() question)

3. testing stability of product

4. Reliability and Stability of Jet/DAO

5. Named Pipe Stability

6. VC 5 stability

7. Override malloc,calloc,realloc and free?

8. malloc, realloc, free questions

9. realloc(): original block after error

10. malloc vs. realloc

11. How to test realloc (and valloc)

12. .::: realloc problem :::.

 

 
Powered by phpBB® Forum Software