[musl] Re: realloci(): A realloc() variant that works in-place

[Laurent Bercot]

>If one wants a reallocf(3) variant, as in the BSDs, it could be
>reallocif().  However, I'd wait to see if anyone is actually interested
>in that before even attempting to implement it; I suspect it could have
>zero users.

  As usual, and this applies to realloci() too, the question is: what
exact problem are you trying to solve?

  What problem is realloci() a solution to? In what circumstance would
a programmer want to use it rather than realloc?

  In most cases, it will be very difficult for an implementation to
increase the size of an allocated block without relocating the block.
So you can expect realloci() to fail often. What should users do in that
case?
  - Fail? the program will not be reliable at all. Who wants that?
  - Fall back on realloc()? then the workarounds for relocation need to
be implemented anyway, so why not use realloc() in the first place?

  When designing an API, you want it to be *usable*. As it is described,
realloci() is not really usable for a programmer. When I want to resize
a chunk of memory, I want to get the memory I asked for and get on with
my day. I don't want the library call to fail, except in a real ENOMEM
situation, which shouldn't happen more than once in two blue moons.

  I already have my own structures and functions to deal with relocation
from realloc(), and every half-decent C programmer around the world,
does as well - that includes implementors of other languages. I see
no reason to ever use realloci(), if it's going to return a failure code
in circumstances I cannot predict while there is ample memory available.
It sounds to me that realloci() is a solution in search of a problem -
and we have more than enough of those already.

--
  Laurent