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 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. jbReceived on Fri Nov 29 2013 - 22:44:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:44 UTC