From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-4022.proton.ch (mail-4022.proton.ch [185.70.40.22]) by sourceware.org (Postfix) with ESMTPS id E0B02385842B for ; Fri, 24 Feb 2023 03:01:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E0B02385842B Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=n8pjl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=n8pjl.ca Date: Fri, 24 Feb 2023 03:01:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=n8pjl.ca; s=protonmail; t=1677207708; x=1677466908; bh=muLcwU8Kzb3h82RYtU1SskskY0NoguAdrca2DzEIK/Y=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=1b9FzuwbwkndQ6CHqK7lvENeQgUhLNwOZ+IeXWRtICiF8AZano/D0kqtU1IIDSD8G wUYbE/TgRit51YLkf8Veox2GIMFJ7LsBxUXUPTrWV2+opmnEETSUvfF3QrQPpI8y1M f07zbzp9QBKyNxsMrZjeLhqLQVY4lkr2W+y5VMD0Ysps8KG27swsWHsAwC2SN8WVmq DoawbHwXHYAPw0B1OIK+ZAeLHPX88Az8j5A7E8qU5YWkjM2NcYwiTGSo5YXCxUmqiF wPGr1lJXMLA3nfNgVwog2xo62iPz2eyMl8IWEKi6vdhHjVZp6lj2Bt1C5tjhHlfher tTUxQP8921VOQ== To: Alex Colomar From: Peter Lafreniere Cc: "Serge E. Hallyn" , Martin Uecker , GCC , Iker Pedrosa , Florian Weimer , Paul Eggert , Michael Kerrisk , =?utf-8?B?SuKCkeKCmeKCmyBHdXN0ZWR0?= , David Malcolm , Sam James , Jonathan Wakely Subject: Re: Missed warning (-Wuse-after-free) Message-ID: 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> Feedback-ID: 53133685:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,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: If I may add my thoughts here, On Thursday, February 23rd, 2023 at 20:42, Alex Colomar wrote: > 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 =3D malloc(42); > if (p =3D=3D NULL) > exit(1); > > q =3D realloc(p, 42); > if (q =3D=3D NULL) > exit(1); > > (void) &p; // If we remove this, we get -Wuse-after-free > > printf("(%p =3D=3D %p) =3D %i\n", p, q, (p =3D=3D q)); > } > alx@dell7760:~/tmp$ cc -Wall -Wextra pointers.c -Wuse-after-free=3D3 > alx@dell7760:~/tmp$ ./a.out > (0x5642cd9022a0 =3D=3D 0x5642cd9022a0) =3D 1 > > > 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: In this case p and q both _do_ point to the same object, which is valid. As per [https://port70.net/~nsz/c/c11/n1570.html#3.15], if the pointers bot= h refer to the same storage region *[1] then they, by definition, refer to th= e same object and so should compare as true. This equality is entirely up to the implementation of your libc's realloc a= nd cannot be depended upon, so the warning is absolutely warranted *[2]. I don= 't believe that it's correct for gcc to do more based off of external implementation-defined behavior. *[1]: Which may or may not need to be sized. I'm not an expert at reading s= pecs, and besides, in this case the pointer is of the same type and value. This p= oint seems more related to aliasing rules than lifetimes. *[2]: There are, however, genuine cases where the reuse could be valid. Nam= ely that if q is null, then p is guaranteed to still point to a valid allocatio= n. Fortunately, I can't get gcc to trigger a false warning in this case. > > http://port70.net/~nsz/c/c11/n1570.html#6.5.9p6 > > > http://port70.net/~nsz/c/c89/c89-draft.html#3.3.9 Just to be transparent, I'm working exclusively off of the first link. Also, this is just a passing interpretation of the c11 spec. > > > (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. Again, this is an issue with defining an object. > 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. -- Cheers, Peter Lafreniere "Who malloc()'s for malloc()?" - Myself, 2023-02-24