From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 11:16:21 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8053717A for ; Fri, 29 Nov 2013 11:16:21 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7A01F21 for ; Fri, 29 Nov 2013 11:16:20 +0000 (UTC) Received: from dhcp-172-17-159-175.eduroam.lapwing.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id rATBGBNf008785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Nov 2013 11:16:13 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: [RFC] how to get the size of a malloc(9) block ? From: David Chisnall In-Reply-To: Date: Fri, 29 Nov 2013 11:16:01 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <933AFE5F-295B-41E0-9D43-14926CC6480D@FreeBSD.org> References: <20131128140637.GA62346@onelab2.iet.unipi.it> To: jb X-Mailer: Apple Mail (2.1822) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 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: Fri, 29 Nov 2013 11:16:21 -0000 On 28 Nov 2013, at 15:13, jb wrote: > Luigi Rizzo iet.unipi.it> writes: >=20 >> ...=20 >> But I don't understand why you find ksize()/malloc_usable_size() = dangerous. >> ... >=20 > 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. >=20 > Some of these guys got it perfectly right: > = http://stackoverflow.com/questions/5813078/is-it-possible-to-find-the-memo= ry-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. David