From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.5 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id D9D731F601 for ; Fri, 9 Dec 2022 15:43:20 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gotplt.org header.i=@gotplt.org header.b="QC53C8ME"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 310A53873CF9 for ; Fri, 9 Dec 2022 15:43:17 +0000 (GMT) Received: from buffalo.birch.relay.mailchannels.net (buffalo.birch.relay.mailchannels.net [23.83.209.24]) by sourceware.org (Postfix) with ESMTPS id 1C90E3858002 for ; Fri, 9 Dec 2022 15:43:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1C90E3858002 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 7963A8C21C4; Fri, 9 Dec 2022 15:43:02 +0000 (UTC) Received: from pdx1-sub0-mail-a306.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E2CD88C1681; Fri, 9 Dec 2022 15:43:01 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1670600582; a=rsa-sha256; cv=none; b=OHcXqGtQ90WJuHhhmIZTJC+s5iX2gDcPV8YKYv7dCEoJG0dVGUA3GTdy59vuKH/SOIQvP/ oOlIbnNjPL7HkMAv2/QeFFWKmcmj2awBXTmr9TnsR/2G49oQr6mHV9tCyJl4gLw/w/giFA cVwVcT8A+4sxtGSNO15JHgfkocOMYM1SXSibvOT+Sfm3EvCi/6aPF/DLWsDY02+LK5UgZC 2waBjmQ5P3vjWK51AeSi3a/k7qxiMScIRK8QxOXQSckp0GSTTj1jxg0YpHRoCdBxCQubCV kl8QS6DpX5w0+HWHqFhYNoZIB2j9qjwgC6cZSxq5ZzMulrEfWRlgLFPkRURCVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1670600582; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=nq5d/D+KoaX4ofHhWhY9DHzRI86HpdoCY0TCsjRMB1I=; b=Xhdv23gvnq7sNam0SqB9g6nw0LlI/lfBqT8T+IjcmQ6HTYtaBLH+WLQiMPKnplrwXcTiEK ah/E2QJ2WE4YgxWVZKK3QnsSKzhaPZZD3TcsI+1STIZ+6RQAy+BJEeWwamf3mp6zAukJRT eM7pGQCeWt8Evc0BzOCsKr65nTghN/rN7z0YWLexGjcb5sUi96raVRYR0+QLB+kS5XF7DV d7uYHq01Zo0bg1W0QmKFbBWqmDEVq28b3nobaJ3jAYxwKUMWlQNTmdZqEBDLoirvRxnpeG zflR44CbWzEMbGrfpP3Qvi2g56Jubwk+W0uXq9OKcU8D1pybBaOVT7CTrRf+zw== ARC-Authentication-Results: i=1; rspamd-85f95c7974-rfmhk; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Desert-Cellar: 0ca85d1371359c01_1670600582264_2144227730 X-MC-Loop-Signature: 1670600582264:2914333344 X-MC-Ingress-Time: 1670600582264 Received: from pdx1-sub0-mail-a306.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.99.229.8 (trex/6.7.1); Fri, 09 Dec 2022 15:43:02 +0000 Received: from [192.168.0.182] (bras-base-toroon4834w-grc-23-76-68-24-147.dsl.bell.ca [76.68.24.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a306.dreamhost.com (Postfix) with ESMTPSA id 4NTFfF1Mv1z47; Fri, 9 Dec 2022 07:43:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1670600581; bh=nq5d/D+KoaX4ofHhWhY9DHzRI86HpdoCY0TCsjRMB1I=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=QC53C8MESdzi+wryoT6pUAKKeIG+Fzu/WMGI2bvIO53Sus7LfPuzaYa3totY10pdN I9EdNaiF+qRuGiGHwDhNAwz9IJYXWUsamNcGJGMB7nock//CwI1eczWs4JH0ThJ2Fn aI92JtwlqsY1Eu3GR3EOlsbcqk9dpJjQJ1FtbqE1OAqqx3MEeNw7Z8IT2b4o6kZLE2 KNWe7qe0ABecEVFnI/QvRIcGhCkK9n4a/F8PBiZ2nu+viS2LQCAVbcLKJ3r4yQ4uO4 obes9apqBpcwLscuRZnJe7lJIQIZdwEU+V9sst7FJlipT7gDVWnZezyRbfALPQCu2T 1jEMEa2PSRGqQ== Message-ID: <32b3937b-9cc8-99e7-ec9b-0b1decc3669b@gotplt.org> Date: Fri, 9 Dec 2022 10:42:59 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [RFC] Supporting malloc_usable_size Content-Language: en-US To: Adhemerval Zanella Netto , Florian Weimer Cc: Zack Weinberg via Libc-alpha , Zack Weinberg , DJ Delorie References: <20221124213258.305192-1-siddhesh@gotplt.org> <87sfhyrp19.fsf@igel.home> <87o7smrnlh.fsf@igel.home> <87pmd2rnce.fsf@oldenburg.str.redhat.com> <5758633c-9989-e463-0eb6-33f483439289@owlfolio.org> <87359tpp1m.fsf@oldenburg.str.redhat.com> <874ju7ilcc.fsf@oldenburg.str.redhat.com> <5728d537-fb16-6943-5793-9291f1cabeba@gotplt.org> From: Siddhesh Poyarekar In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 2022-12-07 11:54, Adhemerval Zanella Netto wrote: > I tend to agree with full deprecation, systemd MALLOC_SIZEOF_SAFE is an > example of what user needs to hack around with an ill defined interface and > _FORTIFY_SOURCE=3 warning should be clear that keep it is not a gain in long > term (besides adding even more trouble for portability). > > Another possibility would to make malloc_usable_size always return the malloc > size argument (although it would add some internal metadata costs). > Do we want to go down this path? I was quite reluctant until I remembered that there's P0401R6 for C++ that would need this kind of information for support anyway. The intent of that paper is different, it's to optimize for realloc and that would actually need us to endorse the chunk size as the actual size when we return it. That would then disallow chunks from being consolidated, thus making usable size consistent through the lifetime of the object. Basically, it looks like one way or another, there's value in making the return value of malloc_usable_size consistent and maybe even usable for writes if we are to support something like P0401R6 in future and instead, help the compiler see this usable size. Thoughts? Thanks, Siddhesh [1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0401r6.html#deallocate