Date: Fri, 29 Nov 2013 11:16:01 +0000 From: David Chisnall <theraven@FreeBSD.org> To: jb <jb.1234abcd@gmail.com> Cc: FreeBSD Current <freebsd-current@FreeBSD.org> Subject: Re: [RFC] how to get the size of a malloc(9) block ? Message-ID: <933AFE5F-295B-41E0-9D43-14926CC6480D@FreeBSD.org> In-Reply-To: <loom.20131128T161159-463@post.gmane.org> References: <CA%2BhQ2%2BiNurBQnmH-4-DN9V-krc_R=dbEaznJkxLDOzkJEWpFMg@mail.gmail.com> <loom.20131128T143120-188@post.gmane.org> <20131128140637.GA62346@onelab2.iet.unipi.it> <loom.20131128T161159-463@post.gmane.org>
index | next in thread | previous in thread | raw e-mail
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. Davidhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?933AFE5F-295B-41E0-9D43-14926CC6480D>