From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 00:03:51 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 A7CA85EF for ; Sat, 30 Nov 2013 00:03:51 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1C80417BA for ; Sat, 30 Nov 2013 00:03:50 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id w7so7285652lbi.36 for ; Fri, 29 Nov 2013 16:03:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vo5U0WBIs91kKtnJFl3cbORTAVo4VzjlpBiL8yj52/c=; b=p2V0fYILdbcn+yATkgDwnokzpZu/LhDfAvW9VWSZYP3YKkSOuKvQj1AVtPHmoacrWF bongEBg0dRrvFKCe5iBpnJlOPLoFmBDN7U9LEIxPj9MtxpoO3WY28boCdbNYoIDRWyoC eyDhNR60WCEY2REmxZVbclm/pBCfvAZgzxanwV6eVOB5tEqfqkKZiRhppgiB2J9KL6ZQ Za8CzlvAd+m9sD84gEKWudEIzM1QhIrvwZk1OQt4Bksqcw6PFdOdA/hObYXa5DPvRb64 +L0smRBhx4yS1A14rVBK5/FCrnwGUHArXKUGz1p0thjBDqjViPGyk05Kg6C1ypC2ChMV PmqQ== MIME-Version: 1.0 X-Received: by 10.152.140.193 with SMTP id ri1mr37626273lab.18.1385769828792; Fri, 29 Nov 2013 16:03:48 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.175.180 with HTTP; Fri, 29 Nov 2013 16:03:48 -0800 (PST) In-Reply-To: References: Date: Fri, 29 Nov 2013 16:03:48 -0800 X-Google-Sender-Auth: Ztbh7sc0ej3fThu3SiDXHC9ch2s Message-ID: Subject: Re: [RFC] how to get the size of a malloc(9) block ? From: Luigi Rizzo To: jb Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 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: Sat, 30 Nov 2013 00:03:51 -0000 On Fri, Nov 29, 2013 at 3:44 PM, jb wrote: > Luigi Rizzo iet.unipi.it> writes: > > > ... > > There is a difference between applications peeking into > > implementation details that should be hidden, and providing > > instead limited and specific information through a well defined API. > > ... > > Right. > > If you want to improve memory management, that is, have the system (kernel > or user space) handle memory reallocation intelligently and transparently > to the user, then aim at a well defined API: > - reallocate "with no copy", which means new space appended (taking into > account *usable size*, a hidden-to-user implementation detail), if > possible > - otherwise fail, and let the user decide about reallocation "with copy" > or allocation of a new space > i respectfully disagree :) but am not pushing to add ksize. Just note that both mine and your "well defined API" leak details: yours is (A) "I may be overallocating but won't tell you how much"; mine is (B) "I may be overallocating and here is exactly how much". Now if I may make a comparison with going shopping, I'd rather hear the final price from the seller (case B), than having to guess by repeated trial and error, which is what case A leads to if i really want to figure out. > The malloc_usable_size() is a hack. > The extra space allocated or not due to fragmentation, alignment, etc, is > an internal by-product, irrelevant to original memory alloc request, and it > should not be leaked, also because its details may change in future API > implementations. > So, these memory allocation functions leaking implementation details, and > the two derived functions, ksize() and malloc_usable_size() (and other > derivatives like malloc_size() in Mac OS X), are a violations of a clean, > safe, and maintainable API. > > Note that malloc_usable_size() is a GNU C Library extension, not part of > Single UNIX Specification. > Honestly i did not even know they existed until a few days ago; but the fact that many different systems have come out with similar extensions at least make me wonder whether the SUS missed it. cheers luigi