From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 11:49:23 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 DE0DBB49; Fri, 29 Nov 2013 11:49:23 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9083910E2; Fri, 29 Nov 2013 11:49:23 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rATBnBKr039184 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 29 Nov 2013 03:49:15 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <52987F32.1010500@freebsd.org> Date: Fri, 29 Nov 2013 19:49:06 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Daniel Nebdal , Gleb Smirnoff Subject: Re: [RFC] how to get the size of a malloc(9) block ? References: <20131128140637.GA62346@onelab2.iet.unipi.it> <20131129105959.GF90895@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Current , jb 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:49:23 -0000 On 11/29/13, 7:26 PM, Daniel Nebdal wrote: > On Fri, Nov 29, 2013 at 11:59 AM, Gleb Smirnoff wrote: > >> On Thu, Nov 28, 2013 at 03:13:53PM +0000, jb wrote: >> j> > But I don't understand why you find ksize()/malloc_usable_size() >> dangerous. >> j> > ... >> j> >> j> The original crime is commited when *usable size* (an implementation >> detail) >> j> is exported (leaked) to the caller. >> j> To be blunt, when a caller requests memory of certain size, and its >> request is >> j> satisfied, then it is not its business to learn details beyond that >> (and they >> j> should not be offered as well). >> j> The API should be sanitized, in kernel and user space. >> j> Otherwise, all kind of charlatans will try to play hair-raising games >> with it. >> j> If the caller wants to track the *requested size* programmatically, it >> is its >> j> business to do it and it can be done very easily. >> >> +1 >> >> This is kind of APIs that just shouldn't exist. >> >> -- >> Totus tuus, Glebius. >> > > Then again: Using the "overflow" memory is only going to bite them if the > API lies : If the return value is exactly "the size of the block you got > allocated and can safely use until you free it", using it will per > definition be safe. If the allocator later changes to, say, always > allocate exact byte ranges, or to allocating blocks but having the option > to fragment them later - then the return value would have to shrink to > match, and any program using it would still DTRT. > > I'm completely ambivalent about adding it, though - it's not something I > need, it's more stuff that needs to be handled if you change/rewrite the > allocator, and it's not my decision. I think that if you want to play games with expanding buffers etc, then you should write your own allocator. You asked for X bytes. you should expect that you get X bytes and nothing more... either that or you should have asked for more in the first place. > > -- > Daniel Nebdal > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >