By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,245 Members | 884 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,245 IT Pros & Developers. It's quick & easy.

More questions on realloc - Thanks

P: n/a
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.
Nov 29 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a

James S. Singleton wrote:
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

Nov 29 '05 #2

P: n/a
David Resnick wrote:
James S. Singleton wrote:
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.

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.
Nov 29 '05 #3

P: n/a

Skarmander wrote:
David Resnick wrote:
James S. Singleton wrote:
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.

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

Nov 29 '05 #4

P: n/a
James S. Singleton <pt***@excite.com> wrote:
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'.

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`
Nov 29 '05 #5

P: n/a
On 2005-11-29, S.Tobias <si***@FamOuS.BedBuG.pAlS.INVALID> wrote:
James S. Singleton <pt***@excite.com> wrote:
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.]
Nov 29 '05 #6

P: n/a
Jordan Abel <jm****@purdue.edu> wrote:
On 2005-11-29, S.Tobias <si***@FamOuS.BedBuG.pAlS.INVALID> wrote:
James S. Singleton <pt***@excite.com> wrote:
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.
Thank you!

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`
Nov 30 '05 #7

P: n/a
On 2005-11-30, S.Tobias <si***@FamOuS.BedBuG.pAlS.INVALID> wrote:
Jordan Abel <jm****@purdue.edu> wrote:
On 2005-11-29, S.Tobias <si***@FamOuS.BedBuG.pAlS.INVALID> wrote:
James S. Singleton <pt***@excite.com> wrote:
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);

--
Nils R. Weller, Bremen (Germany)
My real email address is ``nils<at>gnulinux<dot>nl''
.... but I'm not speaking for the Software Libre Foundation!
Dec 1 '05 #8

P: n/a
Nils Weller <me@privacy.net> wrote:
On 2005-11-30, S.Tobias <si***@FamOuS.BedBuG.pAlS.INVALID> wrote:


....
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);

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.

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`
Dec 1 '05 #9

P: n/a
On 2005-12-01, S.Tobias <si***@FamOuS.BedBuG.pAlS.INVALID> wrote:
Nils Weller <me@privacy.net> wrote:
On 2005-11-30, S.Tobias <si***@FamOuS.BedBuG.pAlS.INVALID> wrote:


...
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);

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.

--
Nils R. Weller, Bremen (Germany)
My real email address is ``nils<at>gnulinux<dot>nl''
.... but I'm not speaking for the Software Libre Foundation!
Dec 1 '05 #10

P: n/a
Nils Weller <me@privacy.net> wrote:
On 2005-12-01, S.Tobias <si***@FamOuS.BedBuG.pAlS.INVALID> wrote:
Nils Weller <me@privacy.net> wrote:
On 2005-11-30, S.Tobias <si***@FamOuS.BedBuG.pAlS.INVALID> wrote:


...
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);

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.

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`
Dec 1 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.