From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bumble.maple.relay.mailchannels.net (bumble.maple.relay.mailchannels.net [23.83.214.25]) by sourceware.org (Postfix) with ESMTPS id F33D73845BDF for ; Wed, 6 Dec 2023 14:30:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F33D73845BDF Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F33D73845BDF Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=23.83.214.25 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1701873037; cv=pass; b=FPfknD3fbGCiP+Pq8Hs4dQonfwa66thJ78gOyK5ATvAxc4ZO4iUabuNjyYT/NJEoA7p/KzYzw/BRMwGFLLacH17ZQtB8iO+xsb6D8j5MDjxYBZhJUGedboQnRRlgCrxwaPGUYjYbapiGLMfftBiRIGDtg0XFapMZ5haAEMjR8Yc= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1701873037; c=relaxed/simple; bh=ji9DxJj92OTiZdHMlJfVDaSMwTF/yxE4FDbrJU2vWi8=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=NonMpwZqP96UnmDKodtp+eKAxyXePjVKjgWCSZPyvvo86oOTS+kPmwUrf94vx2afcReTJ4M1/ug2LkKTTd6umoozLTlFICcF0TGAqF7D4UvTpTWFmKZiaGirfNChoS6HkDsO59XYRIsZcS+QjXE5d1vQZLEu8J+/8YDqKuC9nBU= ARC-Authentication-Results: i=2; server2.sourceware.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 D3D167A1451; Wed, 6 Dec 2023 14:30:34 +0000 (UTC) Received: from pdx1-sub0-mail-a296.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 800B27A1EF8; Wed, 6 Dec 2023 14:30:34 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1701873034; a=rsa-sha256; cv=none; b=Kwj1OWn7RksO7XD22qIEFsnxmEXMELPKjrI356Y6vOsWFelTtmIkUCnALX6EP8AENtwkro LJfpyymaxwjQx3Ucr/M25E77fnibi8/uYWzi13CYluiJKfiB0i3MK8/iuY5sWwGzE2X9o+ DnwbIbhsgLZyMceJJ9Y9amm1LwkMpBRQN8eBgmJHkQlvbitQAE9xTPMMNEpmpI17ublU3E sLTQ+f29mG2yy6baa4U0rcM5w57crAb4tbeMKyhFEXedf5Ai2t7h4U602XcCf9Y8Y2nAJJ SXG2HCRSf7AH0u6NcWeoYpZfgCoE1NR0HdGf7sHVc0a4uhA4Jq4niOTMQdBQ1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1701873034; 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=HjZgQLovdT9x6ZX/p6Gu/EMtjJYdc2m42nWzS49rv8U=; b=XbOn1kPxLrVEPpuChvZP4N+NjbOSaCThdkqhSi4AKdDUfnJwBo54b6gqxsI2OYp1ySpmMh iT1TLSREqjswTyM04tgODpZtpLIfG8JlY9SsJSWN1d0xDkmadb8FboCHS/HOJKpdvnS4M5 83wbnB4IOrMAbTVAL71CbCImgSJlZ7cA8gAQE+aw+CrMHobPN2qQEm7C3qmuuCu6uuI/mO ynzIL8P9L1mDZ+GaBxW5CQj3iuqRG2VZeW5VsPSfRnAIZyjcLXpadx2xzx5/VPQSZq82h2 sBzM0xFhZZO8YF80RDQr7WvjIxIS76+Kz3t+NS8XilKVkMVw2+Hy/pCxe0/YPw== ARC-Authentication-Results: i=1; rspamd-d88d8bd54-4lxns; 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-Shrill-Tank: 6dc0f3ce09339b2a_1701873034711_1730124066 X-MC-Loop-Signature: 1701873034711:4282927238 X-MC-Ingress-Time: 1701873034711 Received: from pdx1-sub0-mail-a296.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.96.209.6 (trex/6.9.2); Wed, 06 Dec 2023 14:30:34 +0000 Received: from [192.168.2.12] (bras-vprn-toroon4834w-lp130-02-142-113-138-136.dsl.bell.ca [142.113.138.136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a296.dreamhost.com (Postfix) with ESMTPSA id 4SlfvY6NsHzDk; Wed, 6 Dec 2023 06:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1701873034; bh=HjZgQLovdT9x6ZX/p6Gu/EMtjJYdc2m42nWzS49rv8U=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=cYUbEVaPuHBkNvhxOEIrLAeSAWleS4lGoBHlIBlYS87tR7beE9f56se00LMHX4G8R +OfHXxErJQkRCdOhhVl6acdy6qFJ7tqkRoQwkX5vV5TLewTfW3dUZXmwsYYH7b8AL2 oeNA/sWGK7FDsWDpVoNsFbXr0/JEi6nAaSJ8Xe6ROnUGmLtykDQQUm+uv1IIstSf2c V+OU4eeDUffgfAPwy7S0WYu61rkOnDIRGN/X3Vj0oTkFA5GanmBWh6P25DmLwyiy5F lJ7oRjaAo43weN4HtNV7DsC/7+clzSYGhdhD7eEKoBRX1/9CybNSlcUsM7D4lasLTa 0g1JxD2MN1AWw== Message-ID: Date: Wed, 6 Dec 2023 09:30:32 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [C PATCH, v2] Add Walloc-size to warn about insufficient size in allocations [PR71219] Content-Language: en-US To: Jakub Jelinek , Martin Uecker Cc: Xi Ruoyao , gcc-patches@gcc.gnu.org, Joseph Myers , Marek Polacek References: <90ccd1f0c61d39d1a3f88007c160bc0983eadf9c.camel@tugraz.at> From: Siddhesh Poyarekar In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3030.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 2023-12-06 09:21, Jakub Jelinek wrote: > On Wed, Dec 06, 2023 at 02:34:10PM +0100, Martin Uecker wrote: >>> Further I think >>> "size less than or equal to the size requested" >>> is quite ambiguous in the calloc case, isn't the size requested in the >>> calloc case actually nmemb * size rather than just size? >> >> This is unclear but it can be understood this way. >> This was also Joseph's point. >> >> I am happy to submit a patch that changes the code so >> that the swapped arguments to calloc do not cause a warning >> anymore. > > That would be my preference because then the allocation size is > correct and it is purely a style warning. > It doesn't follow how the warning is described: > "Warn about calls to allocation functions decorated with attribute > @code{alloc_size} that specify insufficient size for the target type of > the pointer the result is assigned to" > when the size is certainly sufficient. > > But wonder what others think about it. +1, from a libc perspective, the transposed arguments don't make a difference, a typical allocator will produce sufficiently sized allocation for the calloc call. > BTW, shouldn't the warning be for C++ as well? Sure, I know, > people use operator new more often, but still, the > allocators are used in there as well. > > We have the -Wmemset-transposed-args warning, couldn't we > have a similar one for calloc, and perhaps do it solely in > the case where one uses sizeof of the type used in the cast > pointer? > So warn for > (struct S *) calloc (sizeof (struct S), 1) > or > (struct S *) calloc (sizeof (struct S), n) > but not for > (struct S *) calloc (4, 15) > or > (struct S *) calloc (sizeof (struct T), 1) > or similar? Of course check for compatible types of TYPE_MAIN_VARIANTs. +1, this could be an analyzer warning, since in practice it is just a code cleanliness issue. Thanks, Sid