Date: Wed, 4 Dec 2013 10:01:38 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: jb <jb.1234abcd@gmail.com>, David Chisnall <theraven@freebsd.org> Subject: Re: [RFC] how to get the size of a malloc(9) block ? Message-ID: <201312041001.38447.jhb@freebsd.org> In-Reply-To: <933AFE5F-295B-41E0-9D43-14926CC6480D@FreeBSD.org> References: <CA%2BhQ2%2BiNurBQnmH-4-DN9V-krc_R=dbEaznJkxLDOzkJEWpFMg@mail.gmail.com> <loom.20131128T161159-463@post.gmane.org> <933AFE5F-295B-41E0-9D43-14926CC6480D@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, November 29, 2013 6:16:01 am David Chisnall wrote: > > On 28 Nov 2013, at 15:13, jb <jb.1234abcd@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. This sounds sensible to me. There might be cases where you'd like to know how much you can grow an allocation by "for free", and M_DONTALLOCATE doesn't help you with that. In general, I don't like malloc_usable_size(). OTOH, this is C, not C# or Python. Foot-shooting is permitted. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201312041001.38447.jhb>