On 28 Nov 2013, at 15:13, jb <jb.1234a...@gmail.com> wrote: > Luigi Rizzo <rizzo <at> iet.unipi.it> writes: > >> ... >> But I don't understand why you find ksize()/malloc_usable_size() dangerous. >> ... > > The original crime is commited when *usable size* (an implementation detail) > is exported (leaked) to the caller. > To be blunt, when a caller requests memory of certain size, and its request is > satisfied, then it is not its business to learn details beyond that (and they > should not be offered as well). > The API should be sanitized, in kernel and user space. > Otherwise, all kind of charlatans will try to play hair-raising games with it. > If the caller wants to track the *requested size* programmatically, it is its > business to do it and it can be done very easily. > > Some of these guys got it perfectly right: > http://stackoverflow.com/questions/5813078/is-it-possible-to-find-the-memory-allocated-to-the-pointer-without-searching-fo
I disagree. I've encountered several occasions where either locality doesn't matter so much or I know the pointer is aliased, and I'd like increase the size of a relatively large allocation. I have two choices: - Call realloc(), potentially copying a lot of data - Call malloc(), and chain two (or more) allocations together. What I'd like to do is call realloc() if it's effectively free, or call malloc() in other cases. The malloc_useable_size() API is wrong though. In the kernel, realloc() already takes a flag and a M_DONTALLOCATE would make more sense, enlarging the allocation if it can be done without doing the allocate-copy-free dance, but returning NULL and leaving the allocation unmodified if not. David _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
