From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by sourceware.org (Postfix) with ESMTPS id BA99B3894C1D for ; Mon, 5 Dec 2022 18:46:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BA99B3894C1D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id B0743320099B for ; Mon, 5 Dec 2022 13:46:09 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 05 Dec 2022 13:46:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1670265969; x= 1670352369; bh=HkSyMHi+/TOcvrP75Oe4kKmSMZaeUTcxcjbM6IawkPc=; b=z wkVVdeWZHAz2A7EaPmizoWss7GpeSfDiDTxs96xhcxcedkiXm35/UWreIZVWnBmh 4jxLCn2d6HMHT9MSbN57ZT3I5zNrYmBe5GmQpLu1ldBDvGxnzrL0tg8gbHz0zpl+ cNoHO0KmBBDDNY4n9mnLZA6UU1LL87+CUDhqghQZ1XVm4RLwzgWRLxaiokr0aq2R ze8V9vj7YswhGdIZmoXyZ4x/QPN0tiWTrB/0FbhaJ9Yu/+e/SXjMAjVtXj5KJv86 k0MH231V05cHYBUuI23kFLrUICF8Wo0BzbDb8mFvHmmmFlK2laH5BKfalaLpx4p1 eIUYNRceUEa3grCsgS4rA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1670265969; x=1670352369; bh=H kSyMHi+/TOcvrP75Oe4kKmSMZaeUTcxcjbM6IawkPc=; b=Bj2VML1UPVCmkbGhD AfLjnjOPDa/8dwGX37LbpAUyPanzmGFAIuOoT2KdJddT9R/RBaJQP7KtE4pVAtuq Vzxj4rDBV5SOCkBH7f+Nl2Mr3h7mVk4mstgm/jDch5B/iieTj+MGolRI9kZMgA9l a7q2jGVln7x4SHdXqA22fft5NmE4ruFHe4GKbe4hVi5FK6VXhP1UGEajyLeyYGWO 9WLErPneEr/mlRzEXuirJzXGnNUpdniEekFbZrEytUpZDafZR7ZoP0xtxffJjZ0u RKKRESJ8RrZJFSH2CLEyhNy1+ZSgA4IHk1adr7266Mf7zGZ1xzx5cQxT6oYDrWVh WPhRA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudeggdduudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtje ertddtfeejnecuhfhrohhmpegkrggtkhcuhggvihhnsggvrhhguceoiigrtghksehofihl fhholhhiohdrohhrgheqnecuggftrfgrthhtvghrnhepgedvueegveefudfhvdffudejhf fgleektdduvdeffedvueeuhfduiefgtdevjeefnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepiigrtghksehofihlfhholhhiohdrohhrgh X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 5 Dec 2022 13:46:08 -0500 (EST) Message-ID: <5758633c-9989-e463-0eb6-33f483439289@owlfolio.org> Date: Mon, 5 Dec 2022 13:46:08 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [RFC] Supporting malloc_usable_size Content-Language: en-US To: libc-alpha@sourceware.org References: <20221124213258.305192-1-siddhesh@gotplt.org> <87sfhyrp19.fsf@igel.home> <87o7smrnlh.fsf@igel.home> <87pmd2rnce.fsf@oldenburg.str.redhat.com> From: Zack Weinberg In-Reply-To: <87pmd2rnce.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2022-12-02 7:39 AM, Florian Weimer via Libc-alpha wrote: > * Andreas Schwab: > >> On Dez 02 2022, Siddhesh Poyarekar wrote: >> >>> However the man page starts with "Although the excess bytes can be >>> overwritten by the application without ill effects" and maybe that >>> reassurance needs to be dropped. >> >> Or perhaps amended: "until the next call to malloc/realloc/free in any >> thread". > > The list will never be complete because glibc can call into the malloc > subsystem internally How about this then? "The excess bytes, if any, are only guaranteed to exist until the next call to malloc/realloc/free in any thread. Note that almost all C library functions are allowed to use malloc internally for scratch space, and the list of functions that do so may change without notice. Only the functions documented as async-signal-safe are guaranteed not to use malloc internally." > or even spontaneously from an internal service thread We don't have any of those now, do we? I'm inclined to say that we _shouldn't_ have any of those. zw