A question on realloc()...

[ankan]

What realloc(ptr, newsize) does is that it adjusts the size of the allocated block (ptr) to newsize, copying the contents to a new location if necessary. The contents are unchanged upto the lesser of the new and old sizes.

My question is ... if the contents are copied to a new location, is it guranteed that the old location is freed, and made available for use again??

(Note: Some versions of realloc work fine if ptr points to a block freed since the last call of malloc, realloc, or calloc, so that the following is legal...
free(ptr);
realloc(ptr, newsize);
But this technique is NOT recommended because not all C implementations preserve memory after it has been freed.)

So? Bye.
Ankan.

Please do correct me if I am wrong. s-)

 

[rpet]

If realloc() was successful (return value != NULL) the old memory is freed.


free(ptr);
realloc(ptr, newsize);


Don't do this with _any_ C-Compiler. If your compiler don't use debug information it won't detect this, and maybe your application when you least expect it.

-- ralf

 

[rpet]

...your application when you...

should be

...your application will crash when you...

Sorry.

 

[ankan]

This is what I came across while reading a document "C Traps and Pitfalls" by Andrew Koenig, AT&T Bell Laboratories.
"... Here is an excerpt from the description of realloc that appears in the System V Interface Definition:
Realloc changes the size of the block pointed to by ptr to size bytes and returns a pointer to the (possibly moved) block. The contents will be unchanged up to the lesser of the new and old sizes.
The Seventh Edition of the reference manual for the UNIX system contains a copy of the same paragraph. In addition, it contains a second paragraph describing realloc:
Realloc also works if ptr points to a block freed since the last call of malloc, realloc, or calloc; thus sequences of free, malloc and realloc can exploit the search strategy of malloc to do storage compaction.
Thus, the following is legal under the Seventh Edition:
free (p);
p = realloc (p, newsize);
This idiosyncrasy remains in systems derived from the Seventh Edition: it is possible to free a storage area and then reallocate it. By implication, freeing memory on these systems is guaranteed not to change its contents until the next time memory is allocated. Thus, on these systems, one can free all the elements of a list by the following curious means:
for (p = head; p != NULL; p = p->next)
free ((char *) p);
without worrying that the call to free might invalidate p->next.
Needless to say, this technique is not recommended, if only because not all C implementations preserve memory long enough after it has been freed. However, the Seventh Edition manual leaves one thing unstated: the original implementation of realloc actually required that the area given to it for reallocation be free first. For this reason, there are many C programs floating around that free memory first and then reallocate it, and this is something to watch out for when moving a C program to another implementation. ..."
Bye.
Ankan.

Please do correct me if I am wrong. s-)

 

[Lim]

There is a standard C. And there is nothing said that this function will work on once freed memory. So it depends on realloc implimentation. This can work on specific platform with specific C implimentation and will not on others. You can do a lot of treacky things with C, but it will only make your program unportable, unreadable, unsupportable ...
As I have found in HP forum one guy used header of allocated memory (some bytes before pointer returned by malloc) to know allocated size and was surprised when with new version of C libraries (with multu-thread support) it stopped working.

I belive it was general question "May I mess with C standard?" - Yes you sure can, but you finaly will pay for it
In standard there is a line in almost each function: ".. in case of ..., the behavior is undefined", in some cases you can try to define this undefined behavior and use it, but I can not find the reason why?