More questions on realloc - Thanks

J

James S. Singleton

Thanks everybody for your replies. I gather that:

a) How to obtain the size of the memory region pointed to by ptr in
realloc(ptr, size) is implementation-dependent.

b) Implementing realloc(ptr, size) using malloc(), memcpy() and free()
alone, without knowing the size of the memory region pointed to by ptr, is
just not possible.
 
D

David Resnick

James said:
Thanks everybody for your replies. I gather that:
b) Implementing realloc(ptr, size) using malloc(), memcpy() and free()
alone, without knowing the size of the memory region pointed to by ptr, is
just not possible.

Sure it is possible. Just inefficient. You can malloc a new
space, free the old (if malloc succeeds), and copy on all calls
to realloc. What you lose is the ability to reuse the existing space
in cases where the new size is <= the old, or in cases where there
is additional free space after the current block. Which is likely a
less than optimal way to do things, but could be good enough.

-David
 
S

Skarmander

David said:
Sure it is possible. Just inefficient. You can malloc a new
space, free the old (if malloc succeeds), and copy on all calls
to realloc. What you lose is the ability to reuse the existing space
in cases where the new size is <= the old, or in cases where there
is additional free space after the current block. Which is likely a
less than optimal way to do things, but could be good enough.
How do you copy memory if you don't know the size of the old region? There
is no way to implement realloc(ptr, size) as a separate function, without
access to the internal memory management structures. If you think otherwise,
please supply the code. I have a feeling you're talking about something else
entirely, but it's unclear what.

If you know the size of the region, then obviously copying works. But the OP
specifically said we don't.

S.
 
D

David Resnick

Skarmander said:
How do you copy memory if you don't know the size of the old region? There
is no way to implement realloc(ptr, size) as a separate function, without
access to the internal memory management structures. If you think otherwise,
please supply the code. I have a feeling you're talking about something else
entirely, but it's unclear what.

You are being charitable assuming I'm talking about something else,
I was just wrong.

-David
 
S

S.Tobias

James S. Singleton said:
b) Implementing realloc(ptr, size) using malloc(), memcpy() and free()
alone, without knowing the size of the memory region pointed to by ptr, is
just not possible.

True, in standard C it's not possible.

But note that `malloc' and `free' are redundant and can be implemented
in terms of `realloc'.
 
J

Jordan Abel

True, in standard C it's not possible.

But note that `malloc' and `free' are redundant and can be implemented
in terms of `realloc'.

free() can't, unless a size request of 0 does not cause an allocation
[which is not guaranteed.]
 
S

S.Tobias

Jordan Abel said:
True, in standard C it's not possible.

But note that `malloc' and `free' are redundant and can be implemented
in terms of `realloc'.

free() can't, unless a size request of 0 does not cause an allocation
[which is not guaranteed.]

#include <stdlib.h>
void my_free(void *p) { while(p = realloc(p,0)) ; }
;-)

Yes, you're right, I was wrong. `realloc(p,0)' is *not* equivalent
to `free(p)' (for non-null `p'). I knew it once, but forgot.
Thank you!
 
N

Nils Weller

Jordan Abel said:
b) Implementing realloc(ptr, size) using malloc(), memcpy() and free()
alone, without knowing the size of the memory region pointed to by ptr, is
just not possible.

True, in standard C it's not possible.

But note that `malloc' and `free' are redundant and can be implemented
in terms of `realloc'.

free() can't, unless a size request of 0 does not cause an allocation
[which is not guaranteed.]

#include <stdlib.h>
void my_free(void *p) { while(p = realloc(p,0)) ; }
;-)

Yes, you're right, I was wrong. `realloc(p,0)' is *not* equivalent
to `free(p)' (for non-null `p'). I knew it once, but forgot.

Most of us do not use C99. The rules in C89 are different; In C89
realloc(p, 0) is in fact equivalent to free(p);
 
S

S.Tobias

Nils Weller said:
....

Most of us do not use C99. The rules in C89 are different; In C89
realloc(p, 0) is in fact equivalent to free(p);
Well, I thought they were the same in both versions. Could you
expand on the equivalence, please?

My understanding has been that `realloc(p,0)' may return non-null
pointer. My interpretation of the last sentence in the "Description"
(in the C89 draft) is that the object pointed by `p' is always freed,
irrespective whether the allocation of zero bytes succeeds or not.
 
N

Nils Weller

Well, I thought they were the same in both versions. Could you
expand on the equivalence, please?

My understanding has been that `realloc(p,0)' may return non-null
pointer. My interpretation of the last sentence in the "Description"
(in the C89 draft) is that the object pointed by `p' is always freed,
irrespective whether the allocation of zero bytes succeeds or not.

The realloc function changes the size of the object pointed to by
ptr to the size specified by size. [...] If size is zero and ptr is
not a null pointer, the object it points to is freed.

The final sentence overrides the first one: The size of the object is
not changed, but *instead* the object is freed. Or else which object's
size should realloc() change, since the only object we had was freed?
(Of course the wording ``changes the size'' is less than perfect and it
may make more sense to speak of two objects - the old, possibly
deallocated one, and the new one - but then, that's probably why it was
changed in C99!)

Returns

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

After the object has been freed, there is no allocated space left to be
returned and so realloc() returns a null pointer.
 
S

S.Tobias

Nils Weller said:
Well, I thought they were the same in both versions. Could you
expand on the equivalence, please?

My understanding has been that `realloc(p,0)' may return non-null
pointer. My interpretation of the last sentence in the "Description"
(in the C89 draft) is that the object pointed by `p' is always freed,
irrespective whether the allocation of zero bytes succeeds or not.

The realloc function changes the size of the object pointed to by
ptr to the size specified by size. [...] If size is zero and ptr is
not a null pointer, the object it points to is freed.

The final sentence overrides the first one: The size of the object is
not changed, but *instead* the object is freed. Or else which object's
size should realloc() change, since the only object we had was freed?
[snip]

Yes, I agree. Thank you.


I didn't find it in the list of changes in the Standard that the semantics
for `realloc' were changed (but then perhaps it wasn't considered to be
a "major" change). Here's what the Rationale says:

# 7.20.3.4 The realloc function
# A null first argument is permissible. If the first argument is not
# null, and the second argument is 0, then the call frees the memory
# pointed to by the first argument, and a null argument may be returned;
^^^^^^
# C99 is consistent with the policy of not allowing zero-sized objects.
#
# A new feature of C99: the realloc function was changed to make it
# clear that the pointed-to object is deallocated, a new object is
# allocated, and the content of the new object is the same as that of
# the old object up to the lesser of the two sizes. C89 attempted to
# specify that the new object was the same object as the old object but
# might have a different address. This conflicts with other parts of
# the Standard that assume that the address of an object is constant
# during its lifetime. Also, implementations that support an actual
# allocation when the size is zero do not necessarily return a null
# pointer for this case. C89 appeared to require a null return value,
^^^^^^^^
# and the Committee felt that this was too restrictive.

It seems that the wording went against the intentions of the Committee,
but it's the words that matter in the end.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top