Re: realloc() - frequency, conditions, or experiences about relocation?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Fri, 21 Jun 2024 21:12:12 +0200, Bonita Montero wrote:

Usually you don't resize the block with a few bytes ...

>
The usual way I use realloc is to maintain separate counts of the number
of array elements I have allocated, and the number I am actually using. A
realloc call is only needed when the latter hits the former. Every time I
call realloc, I will extend by some minimum number of array elements (e.g.
128), roughly comparable to the sort of array size I typically end up
with.
>
And then when the structure is complete, I do a final realloc call to
shrink it down so the size is actually that used. Is it safe to assume
such a call will never fail? Hmm ...

It's not safe to assume that a shrinking realloc call will never fail.
It's possible that it will never fail in any existing implementation,
but the standard makes no such guarantee.

A (perhaps) plausible way it can fail is if allocations of different
sizes are allocated from different pools.  Trying to shrink a 1000-byte
object to 100 bytes might fail if the 100-byte pool has been exhausted.
On the other hand, realloc() could just return its argument in such a
case and continue treating the object as a 1000-byte allocation.
(The allocation functions don't have to keep track of how much memory
you asked for, only how much they actually allocated, which is >= what
you asked for.)

Arguably only a poor implementation would fail on a shrinking realloc(),
but the standard permits poor implementations.

Having said all that, if realloc fails (indicated by returning a null
pointer), you still have the original pointer to the object.

Something else that occurs to me: If a shrinking realloc() never fails
in practice, then any code you write to handle a failure won't be
tested.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */