On 9/20/22 20:35, baiyang wrote:
> > So what you're actually trying to do is more clear now.
> > And this is something that you should do on the “application layer”,
> > not expect the libc to magically taking care of this.
>
> Yes, we just do this at the application layer with the help of APIs 
> such as malloc_usable_size. You can look at the previous emails, isn't 
> that what we're discussing?
>
> > They want to know if realloc will resize the allocation in-place so
> > the internal memcpy will not happen.
> > AIUI, what they really need is not "usable_size", but "cost estimation
> > for resizing allocation at pointer P to size S". Which I believe they
> > try to deduce from malloc_usable_size.
>
> Yes, from malloc_usable_size, the size that the application layer 
> actually needs to copy, and other parameters like the OS, allocator, etc.
>
At this point it feels more and more like malloc basically can't fulfill 
your needs unless every implementation out there starts adding 
specialized methods for your application. In other words, it might be 
more productive for you to simply bring in a more agreeable allocator, 
instead of trying to get every single allocator out there to bow down to 
your needs.