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 982BA385840F for ; Fri, 24 Feb 2023 08:43:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 982BA385840F 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 4PNNhg3m1Gz3x4Q; Fri, 24 Feb 2023 09:43:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1677228213; bh=PWMK67Nj1LXcaPvxmRnQ3xDydSTlCAE48ZlTYYcxIqY=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=WpOmZsH1OkTrrXGeonCEPOhEoVoYo0IGjLeRcxpnqeuCSvy++mAqHu3T9gMwCU3uD hLnKkAqQs9/Nmj6gyciBI6/wUQhc96blMZK6hNbPS+pQhzK667t4wdzBrYPhv1SsFw GHoTV9XSwmbFQKKbp4IzlQyBR2ByIM1KR7Mv3FKg= Message-ID: <7509225948e17179bd11902544370c7ec28c0a51.camel@tugraz.at> Subject: Re: Missed warning (-Wuse-after-free) From: Martin Uecker To: Alex Colomar , "Serge E. Hallyn" Cc: 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:43:31 +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> <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: 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.116 X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,BODY_8BITS,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 02:42 +0100 schrieb Alex Colomar: > Hi Serge, Martin, > > On 2/24/23 02:21, Serge E. Hallyn wrote: > > > Does all this imply that the following is well defined behavior (and shall > > > print what one would expect)? > > > > > >    free(p); > > > > > >    (void) &p; // take the address > > >    // or maybe we should (void) memcmp(&p, &p, sizeof(p)); ? > > > > > >    printf("%p\n", p); // we took previously its address, > > >                        // so now it has to hold consistently > > >                        // the previous value > > > > > > > > > This feels weird. And a bit of a Schroedinger's pointer. I'm not entirely > > > convinced, but might be. > > > > Again, p is just an n byte variable which happens to have (one hopes) > > pointed at a previously malloc'd address. > > > > And I'd argue that pre-C11, this was not confusing, and would not have > > felt weird to you. > > > > But I am most grateful to you for having brought this to my attention. > > I may not agree with it and not like it, but it's right there in the > > spec, so time for me to adjust :) > > I'll try to show why this feels weird to me (even in C89): > > > alx@dell7760:~/tmp$ cat pointers.c > #include > #include > > > int > main(void) > { > char *p, *q; > > p = malloc(42); > if (p == NULL) > exit(1); > > q = realloc(p, 42); > if (q == NULL) > exit(1); > > (void) &p; // If we remove this, we get -Wuse-after-free > > printf("(%p == %p) = %i\n", p, q, (p == q)); > } > alx@dell7760:~/tmp$ cc -Wall -Wextra pointers.c -Wuse-after-free=3 > alx@dell7760:~/tmp$ ./a.out > (0x5642cd9022a0 == 0x5642cd9022a0) = 1 > No, you can't do the comparison or use the value of 'p' because 'p' is not a valid pointer. (The address taken makes no difference here, but it may confuse the compiler so that it does not warn.) > > This pointers point to different objects (actually, one of them doesn't > even point to an object anymore), so they can't compare equal, according > to both: > > > > > > (I believe C89 already had the concept of lifetime well defined as it is > now, so the object had finished it's lifetime after realloc(3)). > > How can we justify that true, if the pointer don't point to the same > object? And how can we justify a hypothetical false (which compilers > don't implement), if compilers will really just read the value? To > implement this as well defined behavior, it could result in no other > than false, and it would require heavy overhead for the compilers to > detect that the seemingly-equal values are indeed different, don't you > think? The easiest solution is for the standard to just declare this > outlaw, IMO. This is undefined behavior, so the comparison can return false or true or crash or whatever.   Martin > > 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. > > Cheers, > > Alex > > > > > -serge > > -- > > GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5 >