From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 01:02:35 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 E06EFB45 for ; Sat, 30 Nov 2013 01:02:35 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 991B41A82 for ; Sat, 30 Nov 2013 01:02:35 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VmYx6-0004t5-6z for freebsd-current@freebsd.org; Sat, 30 Nov 2013 02:02:32 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Nov 2013 02:02:32 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Nov 2013 02:02:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: jb Subject: Re: [RFC] how to get the size of a malloc(9) block ? Date: Sat, 30 Nov 2013 01:02:11 +0000 (UTC) Lines: 48 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0) 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 01:02:35 -0000 Luigi Rizzo iet.unipi.it> writes: > ... > > 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. > ... This is not necessarily true - I omitted the details of reallocation implementation on purpose. >From the caller's point of view, if it requested allocation of memory size, then that's what it wanted in the first place. If it got it, then there is no other info needed. Next, if the caller came to the conclusion that more would be needed, then it should ask for memory reallocation, trusting that the system will do it in the most efficient way. If the caller wants to influence that process, then proper option(s) are needed in reallocation API, e.g.: - with no copy - with copy That means one call with options, with a specific (wanted by user) result. Of course, thinking thru the options (default, mutual exclusion, etc) is an important process and subject to RFC. A user-empowering API. No magic, no hacks. So, how about Request-for-Enhancement to GNU C lib, and the ugly hacks will disappear quickly. jb