From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 14:38:50 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 09BB5329 for ; Mon, 2 Dec 2013 14:38:50 +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 B42A61877 for ; Mon, 2 Dec 2013 14:38:49 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VnUe3-000476-Ag for freebsd-current@freebsd.org; Mon, 02 Dec 2013 15:38:47 +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 ; Mon, 02 Dec 2013 15:38:43 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Dec 2013 15:38:43 +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: Mon, 2 Dec 2013 14:38:23 +0000 (UTC) Lines: 45 Message-ID: References: <52995C15.7010903@gmx.com> 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.17 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: Mon, 02 Dec 2013 14:38:50 -0000 Luigi Rizzo iet.unipi.it> writes: > ... > > So far, the options could be as follows: > > - realloc_flags(p, s, option) > > where option is one or a combination (where appropriate) of: > > REALLOCF_ANY - default (move or no-move; regular > > realloc()) > > REALLOCF_NO_MOVE - no-move > > REALLOCF_ELASTIC - combined with REALLOCF_NO_MOVE > > REALLOCF_FORCE - combined with REALLOCF_NO_MOVE > > REALLOCF_FALLBACK_ANY - combined with REALLOCF_NO_MOVE or its > > derivatives like REALLOCF_ELASTIC, etc > > > > just five ? for a (quote) "clean, safe and maintainable API", > I'd probably also add a few more, such as > REALLOCF_ALWAYS to trigger bugs on bad assumptions in the code, > REALLOCF_I_AM_FEELING_LUCKY for the newbies, and > REALLOCF_REAL_PROGRAMMERS_NEVER_DO_THAT_I_WILL_PANIC > for skilled folks. > ... These are more or less part of current implementation of realloc() :-) But seriously, the new API takes advantage of current logic - the no-move is already implemented as part of default. It will not (and should not) interfere with current implementation-specific details; it will just be smarter and useful thru its options by asking specific requests, some of which could be already be partially satisified now (think of that extra, unused allocated space, if present), thus giving a programmer more power in one call. Adding some if-else logic and perhaps limited code restructuring will yield a really powerful, functional API. Some of the hidden bugs in current realloc() & co, if any, will be discovered during testing of new implementation (which will be more specific and thus less forgiving). Think of it as being presented with a chance to become part of history, as a co-creator of a new-and-improved memory management function, admittedly being many OS' and libraries' Achilles' heel :-) jb