From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 12:36:38 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 EAEA7C1E for ; Mon, 2 Dec 2013 12:36:38 +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 A37321FDC for ; Mon, 2 Dec 2013 12:36:38 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VnSjn-0004uU-TI for freebsd-current@freebsd.org; Mon, 02 Dec 2013 13:36:36 +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 13:36:31 +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 13:36:31 +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 12:36:11 +0000 (UTC) Lines: 31 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 12:36:39 -0000 gmx.com> writes: > > So new flags could be [1]: > - realloc_flags(p, s, REALLOCF_NO_MOVE) > ... > - realloc_flags(p, s, REALLOCF_NO_MOVE | REALLOCF_ELASTIC) > ... > For this, there could be a REALLOCF_FORCE flag In case of realloc_flags() failing the request, to avoid unnecessary followups with regular realloc() when desired, we should include an option like REALLOCF_FALLBACK_ANY that would allow to fallback on the regular realloc() logic, in one call. In addition, because I have an impression that realloc_flags() may have a future as a replacement for regular realloc() and we should aim for it, we should include an option like REALLOCF_ANY for that purpose. 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 jb