Re: [RFC] how to get the size of a malloc(9) block ?

Luigi Rizzo <rizzo <at> iet.unipi.it> writes:

> ...
> > If you want to improve memory management, that is, have the system (kernel
> > or user space) handle memory reallocation intelligently and transparently
> > to the user, then aim at a well defined API:
> > - reallocate "with no copy", which means new space appended (taking into
> >   account *usable size*, a hidden-to-user implementation detail), if
> >   possible
> > - otherwise fail, and let the user decide about reallocation "with copy"
> >   or allocation of a new space
> >
> 
> i respectfully disagree :) but am not pushing to add ksize.
> Just note that both mine and your "well defined API" leak details:
> 
> yours is (A) "I may be overallocating but won't tell you how much";
> mine is  (B) "I may be overallocating and here is exactly how much".
> 
> Now if I may make a comparison with going shopping,
> I'd rather hear the final price from the seller (case B),
> than having to guess by repeated trial and error,
> which is what case A leads to if i really want to figure out.
> ...

This is not necessarily true - I omitted the details of reallocation
implementation on purpose.
>From the caller's point of view, if it requested allocation of memory 
size, then that's what it wanted in the first place. If it got it, then
there is no other info needed.
Next, if the caller came to the conclusion that more would be needed, then
it should ask for memory reallocation, trusting that the system will do it
in the most efficient way.
If the caller wants to influence that process, then proper option(s) are
needed in reallocation API, e.g.:
- with no copy
- with copy
That means one call with options, with a specific (wanted by user) result.
Of course, thinking thru the options (default, mutual exclusion, etc) is
an important process and subject to RFC.
A user-empowering API. No magic, no hacks.

So, how about Request-for-Enhancement to GNU C lib, and the ugly hacks
will disappear quickly.

jb