From owner-freebsd-current@FreeBSD.ORG Wed Dec 4 15:29:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5271282; Wed, 4 Dec 2013 15:29:45 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8A80518A2; Wed, 4 Dec 2013 15:29:45 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 92DD6B98A; Wed, 4 Dec 2013 10:29:44 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: [RFC] how to get the size of a malloc(9) block ? Date: Wed, 4 Dec 2013 10:01:38 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <933AFE5F-295B-41E0-9D43-14926CC6480D@FreeBSD.org> In-Reply-To: <933AFE5F-295B-41E0-9D43-14926CC6480D@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201312041001.38447.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 04 Dec 2013 10:29:44 -0500 (EST) Cc: jb , David Chisnall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 15:29:45 -0000 On Friday, November 29, 2013 6:16:01 am David Chisnall wrote: > > On 28 Nov 2013, at 15:13, jb wrote: > > > Luigi Rizzo 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