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.


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

Reply via email to