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 1DF483858C31 for ; Fri, 17 Feb 2023 08:12:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1DF483858C31 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 fbmtpc21.tugraz.at (fbmtpc21.tugraz.at [129.27.144.40]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4PJ4LP3dfsz3wnb; Fri, 17 Feb 2023 09:12:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1676621566; bh=jj25R7nzZiH4eMnEOn7uadjbFjeAfBeMFI1F1BUAxO0=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=YZkjTJkEqiSCeGGU1/6MxWYNBEdEJQvDxK9r/D+LiZf6fj+p93omq0u7ZVy94chrS v4B1T9zdAzM5q3lHoJtiGUFAEOMHmzzVeDmrv58VYRS7IFb2zNiqEIQVhDbpu8pFAE zn2F+KZ/y2mG675eupclMAvrzKRm1wUYM2PBpAE0= Message-ID: <2148ef80dee2a034ee531d662fc8709d26159ec5.camel@tugraz.at> Subject: Re: Missed warning (-Wuse-after-free) From: Martin Uecker To: Alejandro Colomar , David Malcolm , GCC Cc: Iker Pedrosa , Florian Weimer , Paul Eggert , Michael Kerrisk , =?UTF-8?Q?J=E2=82=91=E2=82=99=E2=82=9B?= Gustedt Date: Fri, 17 Feb 2023 09:12:45 +0100 In-Reply-To: <23d3a3ff-adad-ac2e-92a6-4e19f4093143@gmail.com> References: <8ed6d28c-69dc-fed8-5ab5-99f685f06fac@gmail.com> <38e7e994a81d2a18666404dbaeb556f3508a6bd6.camel@redhat.com> <23d3a3ff-adad-ac2e-92a6-4e19f4093143@gmail.com> 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=-4.1 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 17.02.2023 um 02:04 +0100 schrieb Alejandro Colomar > > [...] > > > > > I'm not convinced that it's useful to the end-user to warn about > > the > > "use of q itself" case. > > I didn't quote the standard because I couldn't find it.  I was > searching in C11, > and it seems that it was only implicitly Undefined Behavior, without > explicit > spelling (the value of the pointer was indeterminate, according to > C11). The value becomes indeterminate according to 6.2.4p2 in C11. An indeterminate value may be a trap representation 3.19.2 If such a trap representation is read (the pointer, not just the pointed-to object), the behavior is undefined according to 6.2.6.1p5. So it is explitely UB and was already in C99 or even before. > Now C23 will better clarify that reading such a pointer value (not > ever dereferencing) is Undefined Behavior. We did not change this for C23. Only the terminology regarding trap representation (now: non-value representation) and indeterminate values (now: indeterminate representation) was revised. There are proposal to define bevahior for such pointers, but I think this would be a mistake. (although somehow I ended up being a co-author of this paper), The reason is that every use of such a pointer  risks running into sublte issues related to pointer  provenance. So in my opinion it would be very useful to warn about all uses of invalid pointers, because fixing this is much easier than understanding and fixing provenance issues which might arise from incorrect use of such pointers. Martin > There was a discussion in linux-man@ some years ago, which now I > realize it > didn't end up being applied (I thought we had applied a patch, but it > seems we > didn't).  I'll check if we still need such a patch (and I guess we > do, since > we're having this conversation). > > Using the pointer is _wrong_.  And by wrong, I mean that it's > Undefined Behavior. > I think that alone is enough to issue a warning.  Especially, since > the compiler > already has that information; otherwise, it couldn't have warned > about line 67 > of my example program.  I could understand if due to optimizations > the compiler > lost that information, so it couldn't warn, but in this case, there's > no excuse. > > The benefit for users?  They'll realize that the code they wrote is > bad.  Not even > suspicious, as some warnings warn about suspicious code.  This case > is > uncontroversially wrong.  That code has no valid reason to be written > that way, > under ISO C. > > Cheers, > > Alex > > > > > Dave > > -- > > GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5