From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 13:29:09 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 56E64D8B for ; Mon, 2 Dec 2013 13:29:09 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C1EAB1329 for ; Mon, 2 Dec 2013 13:29:08 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id b8so2074482lan.41 for ; Mon, 02 Dec 2013 05:29:06 -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=Zmz5QXaXd5xdzBCVQvr9e1NHqrrlvINaIcv4lm+oR8Q=; b=l4Qgt0i19LRlV/t8ocVmkXoJZYuZ+rSjuKqXWkr5QOyOmx/J8h5h08R2fzbOs/5zuM BdFEKekWdTzDm8izKM+CtgMUvjY4jw1MX6Bbbn1gix6GnrayKcp3EvNnnR/bPbVkv6vY Kaa7DaTC5MsLjUSIHOenCe2t0vQwkl4hQZxv45z3NhKILfSCAjm292LxsJiSrUMxCcPz grXvpx8x7r9GvW3WRAvwwnIkvnCbvubhLNBnxgN08UFzC6v1oz79moVwTP8HeN246nBH Sgkojcb9i7wno4B5WTJ1iu8XEmJDeEytQLjOp1AobA/V3WYm34RFd8az5xINc+2j1qZF Kc8w== MIME-Version: 1.0 X-Received: by 10.152.234.75 with SMTP id uc11mr1021546lac.30.1385990946776; Mon, 02 Dec 2013 05:29:06 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.175.180 with HTTP; Mon, 2 Dec 2013 05:29:06 -0800 (PST) In-Reply-To: References: <52995C15.7010903@gmx.com> Date: Mon, 2 Dec 2013 05:29:06 -0800 X-Google-Sender-Auth: 5DURvJ-ZaMWiDhKZP6DdtzTdKe0 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.17 Cc: freebsd-current 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 13:29:09 -0000 On Mon, Dec 2, 2013 at 4:36 AM, jb wrote: > 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 > 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. I am not sure they are enough to cover the spectrum of possible options, but there are at least 32 bits in the flags so we have a few more left. cheers luigi