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:
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.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"