From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay.tugraz.at (mailrelay.tugraz.at [129.27.2.202]) by sourceware.org (Postfix) with ESMTPS id 32F7F385840D for ; Tue, 19 Dec 2023 17:45:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 32F7F385840D Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tugraz.at ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 32F7F385840D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=129.27.2.202 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703007955; cv=none; b=h564w/GykyDPGOEMkfsaqWyH2VCc41LmopHuzj46e5axl6gOADjs3GaLhEaZ9k/0RX8Vc8Z+GexEeNZItOVgcUHx6AvB8nMa1y1+uaeXmtRi1hP8XnyYqpEGuDEijXNTqjAnsIcRtMOxywHbgz06EdtZe78nppVImUi4gaolpvE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703007955; c=relaxed/simple; bh=Nqr8V+ManwgHfYHqWUeToJq1xAZ5NisroyNeQjxn7Fw=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=kZM2VkXbEDyq/Z2utlF8prhtg8eg3AZiszTFcpCYXzNKX2LvNMT579haoCOZEPHSlxp2st+nkjWZGnxrh9SvDkY5pesmkCvl57WvfiI4/Y3oyUZwWl9wYiXZznRA30QfryQ6t/0KfXemxi7EuNc+lktq7AxfpLAIjOCxbH0Fp08= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [192.168.0.221] (84-115-220-210.cable.dynamic.surfer.at [84.115.220.210]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4Svkcq06nzz3wgg; Tue, 19 Dec 2023 18:45:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1703007947; bh=JtbQNghC5+GUl1EHqIX8KO3CZrXxcwCXDLgBRAKiEhw=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=ig6bMsNotnCE4Vr31HSi03INmaVjdKUkA7RyvkW9q/rOLPKvYqLlNcCAqKMdDsDz9 Uk2HdpeDuLDEQLkM1DP3F7YUgS1Dc2mLonxX0qdNZiMR55WKukJbgg6psEPWZK9xct Bef2klirGz++pfwqAclTQx8bd2pmqTWhwYhc5nmM= Message-ID: <5f795760d3d6696af317fb0b402c9c102936eb73.camel@tugraz.at> Subject: Re: [PATCH] c: Split -Wcalloc-transposed-args warning from -Walloc-size, -Walloc-size fixes From: Martin Uecker To: Jason Merrill , Jakub Jelinek Cc: "Joseph S. Myers" , Marek Polacek , Richard Biener , gcc-patches@gcc.gnu.org Date: Tue, 19 Dec 2023 18:45:46 +0100 In-Reply-To: <6a303c5f-8c7a-435f-b823-fa00f3376471@redhat.com> References: <6a303c5f-8c7a-435f-b823-fa00f3376471@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-TUG-Backscatter-control: G/VXY7/6zeyuAY/PU2/0qw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_MSPIKE_H3,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: Am Dienstag, dem 19.12.2023 um 12:20 -0500 schrieb Jason Merrill: > On 12/19/23 03:47, Jakub Jelinek wrote: > > On Tue, Dec 19, 2023 at 08:11:11AM +0100, Martin Uecker wrote: > > > Am Montag, dem 18.12.2023 um 20:14 +0100 schrieb Jakub Jelinek: > > > > Hi! > > > >=20 > > > > The following patch changes -Walloc-size warning to no longer warn > > > > about int *p =3D calloc (1, sizeof (int));, because as discussed ea= rlier, > > > > the size is IMNSHO sufficient in that case, for alloc_size with 2 > > > > arguments warns if the product of the 2 arguments is insufficiently= small. > > > >=20 > > > > Also, it warns also for explicit casts of malloc/calloc etc. calls > > > > rather than just implicit, so not just > > > > int *p =3D malloc (1); > > > > but also > > > > int *p =3D (int *) malloc (1); > > > >=20 > > > > It also fixes some ICEs where the code didn't verify the alloc_size > > > > arguments properly (Walloc-size-5.c testcase ICEs with vanilla trun= k). > > > >=20 > > > > And lastly, it introduces a coding style warning, -Wcalloc-transpos= ed-args > > > > to warn for calloc (sizeof (struct S), 1) and similar calls (regard= less > > > > of what they are cast to, warning whenever first argument is sizeof= and > > > > the second is not). > > >=20 > > > I would generally see function arguments that are swapped relative > > > to the documented ABI as more than a coding style issue even in > > > cases where it can be expected to make no difference. > >=20 > > If you have suggestions how to reword the documentation, would that be > > sufficient for you? I still don't see why given correct alignment one = can't > > store struct S into sizeof (struct S) sized heap char array, >=20 > Seems to me one can in C++, anyway. An unsigned char array can provide= =20 > storage for another type, and the call to calloc can be interpreted as= =20 > creating such an array if that gives the program defined behavior. > https://eel.is/c++draft/intro.object#def:provides_storage > https://eel.is/c++draft/intro.object#def:object,implicit_creation This is also true in C. There is nothing wrong with calloc(10, 1) allocating a char array with 10 elements and then storing a struct of size 10 in it. Martin >=20