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 E2F423858C00 for ; Thu, 23 Feb 2023 19:57:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E2F423858C00 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-170-37.tugraz.at (vra-170-37.tugraz.at [129.27.170.37]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4PN3hW2f2Lz1LM0L; Thu, 23 Feb 2023 20:57:15 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4PN3hW2f2Lz1LM0L DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1677182237; bh=blb8IRYuVpxHT+0kb9Sdc1/3VEnSOVhkhVU20VE61jI=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=hrtPjN1DSI9kNwdLNZDk71dhm7PS7IMmDEDMalf7l8VNRJnrSUtj+YNCxdUi/Hy78 wJUYOMcU/OBmYHF+orq5Y+2Y0O4k/D2ZM+x0487XinJC3OLSg6cuf6ddgdWxWmWNBO 35+b2J7SOyxqxABWet4e41eesWu3a6hOPqJ63cmE= Message-ID: Subject: Re: Missed warning (-Wuse-after-free) From: Martin Uecker To: Alex Colomar , GCC , Jonathan Wakely Cc: 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 , Serge Hallyn Date: Thu, 23 Feb 2023 20:57:14 +0100 In-Reply-To: References: <8ed6d28c-69dc-fed8-5ab5-99f685f06fac@gmail.com> <38e7e994a81d2a18666404dbaeb556f3508a6bd6.camel@redhat.com> <23d3a3ff-adad-ac2e-92a6-4e19f4093143@gmail.com> <2148ef80dee2a034ee531d662fc8709d26159ec5.camel@tugraz.at> <0049730a-e28c-0e0f-8d92-695395f1ec21@gmail.com> <6edeb3c197c327c1c6639d322c53ec6056039a33.camel@tugraz.at> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1+deb11u1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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.8 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 Donnerstag, dem 23.02.2023 um 20:23 +0100 schrieb Alex Colomar: > Hi Martin, > > On 2/17/23 14:48, Martin Uecker wrote: > > > This new wording doesn't even allow one to use memcmp(3); > > > just reading the pointer value, however you do it, is UB. > > > > memcmp would not use the pointer value but work > > on the representation bytes and is still allowed. > > Hmm, interesting. It's rather unspecified behavior. Still > unpredictable: (memcmp(&p, &p, sizeof(p) == 0) might evaluate to true or > false randomly; the compiler may compile out the call to memcmp(3), > since it knows it won't produce any observable behavior. > > No, I think several things get mixed up here. The representation of a pointer that becomes invalid does not change. So (0 === memcmp(&p, &p, sizeof(p)) always evaluates to true. Also in general, an unspecified value is simply unspecified but does not change anymore. Reading an uninitialized value of automatic storage whose address was not taken is undefined behavior, so everything is possible afterwards. An uninitialized variable whose address was taken has a representation which can represent an unspecified value or a no-value (trap) representation. Reading the  representation itself is always ok and gives consistent results. Reading the variable can be undefined behavior iff it is a trap representation, otherwise you get the unspecified value which is stored there. At least this is my reading of the C standard. Compilers are not full conformant. Martin