On Fri, Nov 29, 2013 at 3:44 PM, jb <jb.1234a...@gmail.com> wrote:

> Luigi Rizzo <rizzo <at> iet.unipi.it> writes:
> > ...
> > There is a difference between applications peeking into
> > implementation details that should be hidden, and providing
> > instead limited and specific information through a well defined API.
> > ...
> Right.
> 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.

> The malloc_usable_size() is a hack.
> The extra space allocated or not due to fragmentation, alignment, etc, is
> an internal by-product, irrelevant to original memory alloc request, and it
> should not be leaked, also because its details may change in future API
> implementations.
> So, these memory allocation functions leaking implementation details, and
> the two derived functions, ksize() and malloc_usable_size() (and other
> derivatives like malloc_size() in Mac OS X), are a violations of a clean,
> safe, and maintainable API.
> Note that malloc_usable_size() is a GNU C Library extension, not part of
> Single UNIX Specification.

Honestly i did not even know they existed until a few days ago;
but the fact that many different systems have come out with similar
extensions at least make me wonder whether the SUS missed it.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to