[cperciva]

The classic example of frequent reallocs is this perl code:

    $x .= $_ while (<>);

I believe this has been fixed now, but perl used to realloc for each append operation, which resulted in O(N^2) time complexity if realloc didn't operate in-place.

[acqq]

But I wouldn't expect of you to assume that a "every time realloc" should be an optimal and at the same time a portable solution in such a case?

[cperciva]

No, I don't. If you look at the code in question, every time I expand an allocation I at least double it.

[acqq]

I'd expect that such growth seldom allows the realloc to remain in-place (unless it's the last thing allocated before and already in a big preallocated chunk of the allocator)? Have you observed what you then get in your program? Which allocator is used underneath?

[cperciva]

I haven't looked. I use whatever allocator is in libc anyway, so it will depend on what platform you're running on.

At worst, using realloc produces the same results as malloc/memcpy/free. At best, it might save a memcpy. No harm in giving it that flexibility.