Does standard C guarantee same memory content after realloc()?

[Jonas]

Hi,

I'm 99 % sure that Standard C guarantees to do a memory move inside
realloc() in case the new, returned memory block (address) is different than
the original one. Can any C expert confirm this to me, please?

Thanks,
Jonas

PS. I using C90, not C99--if it makes a difference.

 

[Andreas Kahari]

Hi,

I'm 99 % sure that Standard C guarantees to do a memory move inside
realloc() in case the new, returned memory block (address) is different than
the original one. Can any C expert confirm this to me, please?

I haven't got the C90 standard in my hand, but SUSv3 (which is a
ISO C superset) says about realloc() that "The contents of the
object shall remain unchanged up to the lesser of the new and
old sizes".

 

[cody]

I'm 99 % sure that Standard C guarantees to do a memory move inside

realloc() in case the new, returned memory block (address) is different than
the original one. Can any C expert confirm this to me, please?

The memory location will only change if at the current position there is no
room for a continous block with the requested size.

 

[Irrwahn Grausewitz]

I haven't got the C90 standard in my hand, but SUSv3 (which is a
ISO C superset) says about realloc() that "The contents of the
object shall remain unchanged up to the lesser of the new and
old sizes".

ISO/IEC 9899:1999 states:

7.20.3.4 The realloc function
[...]
2 The realloc function deallocates the old object pointed to by ptr
and returns a pointer to a new object that has the size specified
by size. The contents of the new object shall be the same as that
of the old object prior to deallocation, up to the lesser of the
new and old sizes. Any bytes in the new object beyond the size of
the old object have indeterminate values.


A draft copy of ANSI C89 I found reads:

4.10.3.4 The realloc function
[...]
The realloc function changes the size of the object pointed to by
ptr to the size specified by size . The contents of the object shall
be unchanged up to the lesser of the new and old sizes. If the new
size is larger, the value of the newly allocated portion of the object
is indeterminate.

Regards

 

[Irrwahn Grausewitz]

The memory location will only change if at the current position there is no
room for a continous block with the requested size.

Maybe true. Maybe not. (At least) C99 does not require this behaviour,
though many implementations will behave like this. However, how does
your statement address the OPs question?

To OP: see my other reply.

Regards

 

[Dan Pop]

You can be safely 100% sure of that. Under both C standards.

The memory location will only change if at the current position there is no
room for a continous block with the requested size.

1. This statement is false. realloc() is free to change the block's
address even if the old size is equal to the new size. Under NO
circumstance is realloc() constrained to return the old address.

2. This has absolutely NOTHING to do with the OP's question! He was
talking about the *contents* of the reallocated memory block, not
about the circumstances when the memory block will have its address
changed.

So, could you, please, stop posting bullshit to this newsgroup?

The actual C89 specification is:

4.10.3.4 The realloc function

Synopsis

#include <stdlib.h>
void *realloc(void *ptr, size_t size);

Description

The realloc function changes the size of the object pointed to by
ptr to the size specified by size . The contents of the object shall
be unchanged up to the lesser of the new and old sizes. If the new
size is larger, the value of the newly allocated portion of the object
is indeterminate. If ptr is a null pointer, the realloc function
behaves like the malloc function for the specified size. Otherwise,
if ptr does not match a pointer earlier returned by the calloc ,
malloc , or realloc function, or if the space has been deallocated by
a call to the free or realloc function, the behavior is undefined. If
the space cannot be allocated, the object pointed to by ptr is
unchanged. If size is zero and ptr is not a null pointer, the object
it points to is freed.

Returns

The realloc function returns either a null pointer or a pointer to
the possibly moved allocated space.

Dan

 

[cody]

I'm 99 % sure that Standard C guarantees to do a memory move inside

You can be safely 100% sure of that. Under both C standards.


1. This statement is false. realloc() is free to change the block's
address even if the old size is equal to the new size. Under NO
circumstance is realloc() constrained to return the old address.

2. This has absolutely NOTHING to do with the OP's question! He was
talking about the *contents* of the reallocated memory block, not
about the circumstances when the memory block will have its address
changed.

So, could you, please, stop posting bullshit to this newsgroup?

Instead of giving stupid and rude comments you should read the original
question.
The OP clearly asked wheather the returned memory address will/might/can be
different than the original one.

You are talking bullshit here. Why in the world should realloc cause the
content of the memory block to be changed???

 

[Mark Gordon]

On Fri, 10 Oct 2003 21:35:31 +0200

Please don't trim out the attribution lines for bits of the message
still quoted.

Instead of giving stupid and rude comments you should read the
original question.

Dan did both read and answer the OPs question.

The OP clearly asked wheather the returned memory address
will/might/can be different than the original one.

No, the OP asked if it does a memory move *when* the return address is
different. I.e. whether he runs the risk of loosing his data.

You are talking bullshit here. Why in the world should realloc cause
the content of the memory block to be changed???

It is allowed to therefor one should allow for the fact it could happen.
As to why it might happen in a real system, it could do it to
consolidate free space.

 

[Irrwahn Grausewitz]

PLEASE do not drop references when quoting!

[quoting restored]

Instead of giving stupid and rude comments you should read the original
question.

I never encountered a stupid comment given by Dan Pop. If you dislike
his, um, direct way of commenting, or consider it rude, feel free to
ignore his posts. But be aware you definitely miss something when doing
so.

The OP clearly asked wheather the returned memory address will/might/can be
different than the original one.

Oh yes? Let's review the subject line of this thread:

"Does standard C guarantee same memory content after realloc()?"

Now, which part of "same memory content" didn't you understand?

You are talking bullshit here.

Hmwah. Hmmwaha. Hmwahaaaha-ha-haaa. Well, I know for sure that /if/
somebody is posting bovine excrement here at all, it is you.

Why in the world should realloc cause the
content of the memory block to be changed???

I do not know, but the question was: is it required by the standard
for realloc to retain the contents of the memory (except that truncation
occurs when the new size is less than the previous size)?
[ Answer: definetely yes, in C89/C90 and C99 ]

Now stop trolling and go read a book on C.

Irrwahn

 

[Default User]

Instead of giving stupid and rude comments you should read the original
question.

Stop spewing a bunch of incorrect information then.

The OP clearly asked wheather the returned memory address will/might/can be
different than the original one.

I think you better reread.

"I'm 99 % sure that Standard C guarantees to do a memory move inside
realloc() in case the new, returned memory block (address) is different
than
the original one. Can any C expert confirm this to me, please?"


The OP already acknowledges that the address may change, he wanted to
know if the data went with it.




Brian Rodenborn

 

[Jonas]

In <[email protected]> "cody"

You can be safely 100% sure of that. Under both C standards.

Ok, thanks. That was the answer I was looking for.

 

[cody]

Oh yes? Let's review the subject line of this thread:

"Does standard C guarantee same memory content after realloc()?"

Now, which part of "same memory content" didn't you understand?

You are talking bullshit here.

Hmwah. Hmmwaha. Hmwahaaaha-ha-haaa. Well, I know for sure that /if/
somebody is posting bovine excrement here at all, it is you.

Why in the world should realloc cause the
content of the memory block to be changed???

I do not know, but the question was: is it required by the standard
for realloc to retain the contents of the memory (except that truncation
occurs when the new size is less than the previous size)?
[ Answer: definetely yes, in C89/C90 and C99 ]

Ok iam sorry. but i cannot understand why the memory content could change.
It is the the purpose of realloc that your data is not lost. it that would
not be guaranteed,
realloc() would simply do a free() and malloc().

 

[Irrwahn Grausewitz]

Oh yes? Let's review the subject line of this thread:

"Does standard C guarantee same memory content after realloc()?"

Now, which part of "same memory content" didn't you understand?

You are talking bullshit here.

Hmwah. Hmmwaha. Hmwahaaaha-ha-haaa. Well, I know for sure that /if/
somebody is posting bovine excrement here at all, it is you.

Why in the world should realloc cause the
content of the memory block to be changed???

I do not know, but the question was: is it required by the standard
for realloc to retain the contents of the memory (except that truncation
occurs when the new size is less than the previous size)?
[ Answer: definetely yes, in C89/C90 and C99 ]

Ok iam sorry. but i cannot understand why the memory content could change.
It is the the purpose of realloc that your data is not lost.

Of course, but the OP wanted to be 100% sure that this behaviour
is guaranteed by the standard, so he can rely upon it, on whatever
conforming implementation his code is built and run.

it that would not be guaranteed,
realloc() would simply do a free() and malloc().

Sure.

Regards

 

[Mark McIntyre]

Instead of giving stupid and rude comments you should read the original question.
The OP clearly asked wheather the returned memory address will/might/can be
different than the original one.

do he didn't. I've no idea if english is your first language, but
whether or not, the original question was "does realloc copy the data
if it has to change the pointer". I've retained it for your perusal
above.

You are talking bullshit here.

No comment.

Why in the world should realloc cause the
content of the memory block to be changed???

It doesn't, and the person you were being rude to didn't say that
either.

 

[Joona I Palaste]

I never encountered a stupid comment given by Dan Pop. If you dislike
his, um, direct way of commenting, or consider it rude, feel free to
ignore his posts. But be aware you definitely miss something when doing
so.

Nor have I encountered one. Dan Pop is very often rude, but he is
nearly always right. Better to be rude and right than to be polite and
wrong.

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"'It can be easily shown that' means 'I saw a proof of this once (which I didn't
understand) which I can no longer remember'."
- A maths teacher

 

[Richard Heathfield]

Nor have I encountered one. Dan Pop is very often rude, but he is
nearly always right. Better to be rude and right than to be polite and
wrong.

How much better it is, though, to be polite and right.

 

[Joona I Palaste]

How much better it is, though, to be polite and right.

Like you Richard? The opposite would be, of course, to be rude and
wrong, like some people we've seen lately on comp.lang.c. I won't name
names but surely you know at least one whom I'm talking about.

 

[Mark McIntyre]

Nor have I encountered one. Dan Pop is very often rude, but he is
nearly always right. Better to be rude and right than to be polite and
wrong.

But better still to be right /and/ polite.
People have a tendency to ignore rude people, right or not, because
its too much trouble to remove the rudeness to get to the kernel of
truth potentially hidden inside.

 

[Richard Heathfield]

Like you Richard?

Um, like I /try/ to be, yes. I don't claim always to succeed.

The opposite would be, of course, to be rude and
wrong, like some people we've seen lately on comp.lang.c. I won't name
names but surely you know at least one whom I'm talking about.

One? ONE?

 

[cody]

The opposite would be, of course, to be rude and

wrong, like some people we've seen lately on comp.lang.c. I won't name
names but surely you know at least one whom I'm talking about.

It isn't me, is it?