Is realloc guaranteed to be in-place when the buffer is shrinking?

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.

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.

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.

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.