From owner-freebsd-current@FreeBSD.ORG Fri Nov 29 11:26:20 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 5221F335; Fri, 29 Nov 2013 11:26:20 +0000 (UTC) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9FFFC1FA2; Fri, 29 Nov 2013 11:26:19 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id u14so6829496lbd.4 for ; Fri, 29 Nov 2013 03:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oTeDx72VQI2mUBRN2chxMdIMJIK4pPs0oW0Tp7/bS58=; b=02PDLz7wm5C38UDd+yzokfxRju03sLFVmwDpmfkY4ZQCZ6ioT00urbyoH02gTJb58y 2RwfjdhpuWYIah2tavLtCanhC1Kf9rYL2Q2LH54Or/4naimDgjxIfivSVhnYz4Bkq97W WP48J4yWl2XVFkHziXHftzA6//cvM/nEX0h2zl9XlABWBdpOpG9LXwAVOR6mXHkpl0RW fn/jLReFVCwK5LADsMgDLS2AhqsY7lirKtseQOZrOiH4V9fyoiXiL75Gxq+iMnZlLHoq ylkQhjpnVwvR0ngVlipsQ5FN7/uC0MCMtZRbbUoz7K8DWC5AZQePVsTJYx6ySpvtRaLC 20Rg== MIME-Version: 1.0 X-Received: by 10.152.21.229 with SMTP id y5mr22254lae.87.1385724377600; Fri, 29 Nov 2013 03:26:17 -0800 (PST) Received: by 10.112.140.132 with HTTP; Fri, 29 Nov 2013 03:26:17 -0800 (PST) In-Reply-To: <20131129105959.GF90895@FreeBSD.org> References: <20131128140637.GA62346@onelab2.iet.unipi.it> <20131129105959.GF90895@FreeBSD.org> Date: Fri, 29 Nov 2013 12:26:17 +0100 Message-ID: Subject: Re: [RFC] how to get the size of a malloc(9) block ? From: Daniel Nebdal To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 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:26:20 -0000 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. -- Daniel Nebdal