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.
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
- otherwise fail, and let the user decide about reallocation "with copy"
or allocation of a new space
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
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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"