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 6FC82385B501 for ; Fri, 24 Feb 2023 08:52:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6FC82385B501 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tugraz.at Received: from vra-173-101.tugraz.at (vra-173-101.tugraz.at [129.27.173.101]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4PNNtn0DmHz3x82; Fri, 24 Feb 2023 09:52:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1677228738; bh=V5UjmEh8Vb/HFWW49AKeW2OCkuH6HusyPtjSx23MhdQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=fFbOtZdA0Uwlp1MqDuWEhksKXYzImT2vaTN7jhvpYrZ20+ovaWBfHBMI4jJE8GAx4 mXpkLdvT+oF/QNb9XvZe+t5EA9pUAAnNibWXVxIrelx5CGSqqSXJaCMtNEleDnvXmJ +y2US4W4OrVwvuNz3EUUPb1PQCIKevaZZGAth+1k= Message-ID: <045dec6a3f28b237863deedf8ae0b244bd269145.camel@tugraz.at> Subject: Re: Missed warning (-Wuse-after-free) From: Martin Uecker To: Peter Lafreniere , Alex Colomar Cc: "Serge E. Hallyn" , GCC , Iker Pedrosa , Florian Weimer , Paul Eggert , Michael Kerrisk , =?UTF-8?Q?J=E2=82=91=E2=82=99=E2=82=9B?= Gustedt , David Malcolm , Sam James , Jonathan Wakely Date: Fri, 24 Feb 2023 09:52:11 +0100 In-Reply-To: References: <8ed6d28c-69dc-fed8-5ab5-99f685f06fac@gmail.com> <2148ef80dee2a034ee531d662fc8709d26159ec5.camel@tugraz.at> <0049730a-e28c-0e0f-8d92-695395f1ec21@gmail.com> <6edeb3c197c327c1c6639d322c53ec6056039a33.camel@tugraz.at> <20230224012114.GA360078@mail.hallyn.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1+deb11u1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,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: Am Freitag, dem 24.02.2023 um 03:01 +0000 schrieb Peter Lafreniere: ... > > > Maybe it could do an exception for printing, that is, reading a pointer > > is not a problem in itself, a long as you don't compare it, but I'm not > > such an expert about this. > > One last thought: with the above strict interpretation of the c standard, > it would become nigh on impossible to implement the malloc(3) family of > functions in c themselves. I vote for the "shared storage" interpretation > of the c11 standard that is actually implemented rather than this abstract > liveness oriented interpretation. This is a bit of a misunderstanding about what "undefined behavior" means in ISO C. It simply means that ISO C does not specify the behavior. This does not mean it is illegal to do something which has undefined behavior. Instead, it means you can not rely on the ISO C standard for portable behavior. So if you implement "malloc" in C itself you will probably rely on "undefined behavior", but this is perfectly fine. The C standard specifies behavior of "malloc", but does not care how it is implemented. Martin