12

Are there any guarantees that realloc() will always shrink a buffer in-place?? So that the following:

new_ptr = (data_type *) realloc(old_ptr, new_size * sizeof(data_type));

will always give new_ptr == old_ptr if new_size < old_size (except of course when new_size == 0). It seems sensible (to me) that it would work this way, but was curious whether the standard enforced it.

I'm looking at the reallocation of arrays of non-POD data types, and if the above behaviour was guaranteed was thinking that the following strategy might at least allow efficient "shrinking":

if (new_size > old_size)
{
    // malloc() a new buffer
    // use placement copy constructor to copy old objects over
    // free() old buffer
}
else
if (new_size < old_size)
{
    // explicit destruction of unneeded objects
    // realloc() buffer
}

I"m expecting that an in-place "shrink" would be robust even if the data type had self references/pointers or whatever...

Darren Engwirda
  • 6,915
  • 4
  • 26
  • 42
  • Thanks for your comments everyone. I guess I just find it pretty wasteful and inefficient to have to alloc a new buffer and do a full copy to achieve a "shrink"... – Darren Engwirda Jul 02 '10 at 00:34
  • Not going to add to the chorus of "no"s here, you should get the idea by now. But one unintended side effect of guaranteeing that the reallocated block reuse the same memory when shrunk is that you couldn't use a [small object allocator](http://www.developer.com/ws/brew/article.php/3315011/Small-Memory-Allocation.htm) inside malloc/realloc, since these allocators group equal-sized objects together. – Mike DeSimone Jul 02 '10 at 00:37
  • Another reason you can't expect realloc to always reuse the same memory is that most general purpose heaps put management information (block size, pointer to next block in heap) in a header right "in front" of the allocated memory. So if you have a block that is sitting between two allocated blocks, and realloced to one word smaller, there would be no room to put the header for the freed word of memory, effectively losing it and permanently fragmenting your heap. – Mike DeSimone Jul 02 '10 at 00:40
  • If you're trying to manage arrays of non-POD data with `malloc` and friends, then you're causing undefined behaviour. Regardless of the answer to this particular question, what you're doing is wrong. Use `new[]` and `delete[]`, or containers such as `std::vector` (which, incidentally, will shrink in place). – Mike Seymour Jul 02 '10 at 02:00
  • 1
    @Mike: Sorry, but I don't agree. Using malloc()/free() etc in conjunction with explicit calls to the ctor/dtor via placement new() etc should be well defined. Most std::vector implementations manage the underlying buffer and object construction separately, not via new[]/delete[]... – Darren Engwirda Jul 02 '10 at 03:42
  • @Darren: I don't see what `new(void*)` and its ilk (much less `new[]` and `delete[]`) has to do with expecting `realloc()` in the shrink case to return the same address. The former is behavior outside `realloc()`, and the latter is behavior inside `realloc()`. – Mike DeSimone Jul 02 '10 at 04:42
  • @Darren: Sorry, I didn't notice the comments about placement new and explicit destruction. Seeing "realloc" and "non-POD" in the same question set off alarm bells, and I must have glossed over the rest. It was late at night, and I should have been asleep. – Mike Seymour Jul 02 '10 at 10:38

5 Answers5

14

No.

That's it. None of this "it may work in some architectures" or "it should, based on experience". The standard states clearly that the address may change so rely on that and nothing more. In any case, you asked if it was guaranteed - the answer that is a definite no(a).

In terms of coding to the standard: do, or do not. There is no "try" :-)

From c99:

The realloc function deallocates the old object pointed to by ptr and returns a pointer to a new object that has the size specified by size. The contents of the new object shall be the same as that of the old object prior to deallocation, up to the lesser of the new and old sizes. Any bytes in the new object beyond the size of the old object have indeterminate values.

If ptr is a null pointer, the realloc function behaves like the malloc function for the specified size. Otherwise, if ptr does not match a pointer earlier returned by the calloc, malloc, or realloc function, or if the space has been deallocated by a call to the free or realloc function, the behavior is undefined. If memory for the new object cannot be allocated, the old object is not deallocated and its value is unchanged.

The realloc function returns a pointer to the new object (which may have the same value as a pointer to the old object), or a null pointer if the new object could not be allocated.

(a) If you're wondering why you wouldn't just split up a buffer into two smaller buffers (keeping one and returning the other to the free list) for efficiency, there is at least one possibility that springs to mind.

If you have different pools for allocations of different sizes (which may use different allocation strategies, for example), it might make sense to move the data over to the pool for smaller allocations. The efficiency gains you get from separate pools may outweigh the gains of leaving memory in place.

But that's just an example, I have no idea whether any implementation does that. As stated, you should rely on what the standard mandates, which is that the memory may move even when shrinking.

Community
  • 1
  • 1
paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
6

No. You shall not rely on this.

According to spec 7.20.3.4/4:

The realloc function returns a pointer to the new object (which may have the same value as a pointer to the old object), or a null pointer if the new object could not be allocated.

czchen
  • 5,850
  • 2
  • 26
  • 17
3

Generally it does, but It is not garanted (it all depend on your architecture). So You should not rely on it on such behavior

EDIT:

reference: http://opengroup.org/onlinepubs/007908775/xsh/realloc.html

Upon successful completion with a size not equal to 0, realloc() returns a pointer to the (possibly moved) allocated space.

Phong
  • 6,600
  • 4
  • 32
  • 61
2

Some allocators use a "bucketizing" strategy where allocations sized from, say, 2^3 through 2^4, go to the same allocation bucket. This tends to prevent extreme cases of memory fragmentation where many small allocations spread across the heap prevent large allocations from succeeding. Obviously, in such a heap manager, reducing the size of an allocation could force it to a different bucket.

David Gladfelter
  • 4,175
  • 2
  • 25
  • 25
1

No, there is no such guarantee. Implementations of realloc may just shrink the buffer in place, but they are not constrained to do so.

haffax
  • 5,898
  • 1
  • 32
  • 30