?: realloc 
Author Message
 ?: realloc

Hi!

I've got a question about realloc. I need to know what realloc will
exactly do in what situation. Unfortunately the interpretation of the
ANSI Standard I've got (The C Programming Language, 2nd Edition by
Kernighan/Ritchie) is way to unexact.

When may the block move in memory?
1) when newsize < oldsize?
2) when newsize = oldsize?
3) when newsize > oldsize?

Shurely in case 3) but what with cases 1) or 2)?
Concerning case 1) you might do the following:
        mem = malloc(4);
        tmp = realloc(mem, 8);
        mem = realloc(tmp, 4);
ignoring the fact that realloc might fail and assuming that the first
call moved the block, might the second call move the block back?
I don't think it will do for performace sake, but what does the standard
say about this? May or may not?
And case 2)?

When may realloc fail? Only in case 3)? Or may it fail also in cases 1)
and 2)?

Ciao,
   Floh!



Wed, 05 Jan 2000 03:00:00 GMT  
 ?: realloc



Quote:
>Hi!

>I've got a question about realloc. I need to know what realloc will
>exactly do in what situation. Unfortunately the interpretation of the
>ANSI Standard I've got (The C Programming Language, 2nd Edition by
>Kernighan/Ritchie) is way to unexact.

>When may the block move in memory?
>1) when newsize < oldsize?
>2) when newsize = oldsize?
>3) when newsize > oldsize?

K&R doesn't make any distinction because there is no distinction to be made.
In all of those cases the implementation is free to leave the object where
it is or move it. Once you've freed or realloc'd an object all pointers
to (any part of) the object that existed before the call are invalid. With
realloc() all pointers to the object must be derived from the realloc's
return value.

Quote:
>Shurely in case 3) but what with cases 1) or 2)?

realloc is at liberty to move the object in those cases if it chooses to.

Quote:
>Concerning case 1) you might do the following:
>        mem = malloc(4);
>        tmp = realloc(mem, 8);
>        mem = realloc(tmp, 4);
>ignoring the fact that realloc might fail and assuming that the first
>call moved the block, might the second call move the block back?

Since the value of mem after the second line is invalid, there is no way
for a C program to tell. However realloc can put the block anywhere
it likes as long as it "works" and doesn't overlap other objects.

Quote:
>I don't think it will do for performace sake, but what does the standard
>say about this? May or may not?
>And case 2)?

Even in case 2.

Quote:
>When may realloc fail? Only in case 3)? Or may it fail also in cases 1)
>and 2)?

Again, the C language doesn't specify under what conditions it fails. It can
fail in all the circumstances you list above. For example a debugging
library might always have realloc copy to a new block of memory so that it
can detect invalid use of old pointers. If it runs out of memory it would
fail in all cases above. Such an implementation is perfectly valid as far
as the C language is concerned.

--
-----------------------------------------


-----------------------------------------



Wed, 05 Jan 2000 03:00:00 GMT  
 ?: realloc

Quote:

> Hi!

> I've got a question about realloc. I need to know what realloc will
> exactly do in what situation. Unfortunately the interpretation of the
> ANSI Standard I've got (The C Programming Language, 2nd Edition by
> Kernighan/Ritchie) is way to unexact.

> When may the block move in memory?
> 1) when newsize < oldsize?
> 2) when newsize = oldsize?
> 3) when newsize > oldsize?

The bottom line is realloc will move blocks as it likes.
However, all implementations I know about will leave the block
alone in case 2. If you want control, get my Vmalloc package
from research.att.com/sw/tools and use the call
        vmresize(Vmheap,current_block,new_size,flags);
flags can be made up from 3 bits: VM_RSMOVE, VM_RSCOPY, VM_RSZERO.
The VM_RSMOVE bit says it's ok to move. The VM_RSCOPY bit says
if it moves, copy the content. The VM_RSZERO says always zeroing
out the new area if getting larger. For example, the realloc
call is exactly the same as:
        vmresize(Vmheap,current_block,new_size,VM_RSMOVE|VM_RSCOPY);
Phong Vo


Fri, 07 Jan 2000 03:00:00 GMT  
 ?: realloc


Quote:

> Hi!

> I've got a question about realloc. I need to know what realloc will
> exactly do in what situation. Unfortunately the interpretation of the
> ANSI Standard I've got (The C Programming Language, 2nd Edition by
> Kernighan/Ritchie) is way to unexact.

> When may the block move in memory?
> 1) when newsize < oldsize?
> 2) when newsize = oldsize?
> 3) when newsize > oldsize?

> Shurely in case 3) but what with cases 1) or 2)?
> Concerning case 1) you might do the following:
>         mem = malloc(4);
>         tmp = realloc(mem, 8);
>         mem = realloc(tmp, 4);
> ignoring the fact that realloc might fail and assuming that the first
> call moved the block, might the second call move the block back?
> I don't think it will do for performace sake, but what does the standard
> say about this? May or may not?
> And case 2)?

> When may realloc fail? Only in case 3)? Or may it fail also in cases 1)
> and 2)?

I know one implementation of malloc/free/realloc that will definitely move
the block when you call realloc to change the size from certain larger
sizes to certain smaller sizes.

Some implementations use some area of memory for all blocks up to 8 bytes,
some area for all blocks up to 16 bytes, 32 bytes, 64 bytes etc. In such
an implementation, realloc (malloc (55), 24) would move the block from the
"64 byte" area to the "32 byte" area.

Such an implementation could even fail when reducing the block size with
realloc (if the "32 byte" area was full). I would not expect this, and I
would call it a low quality implementation, but I think it is allowed by
the C standard.

-- For email responses, please remove the last emm from my address.



Fri, 07 Jan 2000 03:00:00 GMT  
 ?: realloc



Quote:
>Hi!

>I've got a question about realloc. I need to know what realloc will
>exactly do in what situation. Unfortunately the interpretation of the
>ANSI Standard I've got (The C Programming Language, 2nd Edition by
>Kernighan/Ritchie) is way to unexact.

>When may the block move in memory?
>1) when newsize < oldsize?
>2) when newsize = oldsize?
>3) when newsize > oldsize?

It may move under all of these circumstances. A program that depends on
realloc not moving the block is not portable.

Quote:
>Shurely in case 3) but what with cases 1) or 2)?
>Concerning case 1) you might do the following:
>    mem = malloc(4);
>    tmp = realloc(mem, 8);
>    mem = realloc(tmp, 4);
>ignoring the fact that realloc might fail and assuming that the first
>call moved the block, might the second call move the block back?

Relying on the block being moved back to its original location is a long shot
in the dark.

Quote:
>I don't think it will do for performace sake, but what does the standard
>say about this? May or may not?
>And case 2)?

>When may realloc fail? Only in case 3)? Or may it fail also in cases 1)
>and 2)?

Realloc may fail in all cases, even if you are shrinking the block.

If you realloc to size zero, it always succeeds, because this case is
equivalent to freeing the pointer.



Fri, 07 Jan 2000 03:00:00 GMT  
 ?: realloc

Quote:

>If you realloc to size zero, it always succeeds, because this case is
>equivalent to freeing the pointer.

No it is equivalent to free(pointer); return(malloc(0));
There are no guarrenttees about the malloc(0).


Tue, 11 Jan 2000 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. malloc()/realloc() vs realloc()

2. Realloc failure when downsizing (was Re: Probably a simple realloc() question)

3. Override malloc,calloc,realloc and free?

4. malloc, realloc, free questions

5. realloc(): original block after error

6. malloc vs. realloc

7. How to test realloc (and valloc)

8. .::: realloc problem :::.

9. realloc() failure

10. realloc() won't work

11. Speed of realloc versus (free, malloc, and memcpy).

12. 'Freeing' storage with realloc

 

 
Powered by phpBB® Forum Software