432,245 Members | 884 Online
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
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 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 wrote: James S. Singleton 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 wrote: On 2005-11-29, S.Tobias wrote: James S. Singleton 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 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 wrote: Jordan Abel wrote: On 2005-11-29, S.Tobias wrote: James S. Singleton 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 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 ``nilsgnulinuxnl'' .... but I'm not speaking for the Software Libre Foundation! Dec 1 '05 #8

 P: n/a Nils Weller wrote: On 2005-11-30, S.Tobias 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 wrote: Nils Weller wrote: On 2005-11-30, S.Tobias 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 ``nilsgnulinuxnl'' .... but I'm not speaking for the Software Libre Foundation! Dec 1 '05 #10

 P: n/a Nils Weller wrote: On 2005-12-01, S.Tobias wrote: Nils Weller wrote: On 2005-11-30, S.Tobias 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.