From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by sourceware.org (Postfix) with ESMTPS id 5DF2F3858C31 for ; Fri, 17 Feb 2023 14:10:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5DF2F3858C31 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x52e.google.com with SMTP id dn12so12465093edb.5 for ; Fri, 17 Feb 2023 06:10:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cy3MpUtv+dRO9JK5z8XYxdENRpbwChC8f/DLqUKE5MI=; b=eB5vrOzMvwDYfXxV6qZwLF+OJdqSl+eT5pJVEEzion7cXM4vK2REC20Nvzco1fddy0 CxNjltHodV/IDlpsxQrDHDqj3uhYrstyPqnL2jx8K5pcghQq/V0sK8wfdHlRd1jGeeEc GDEYuZILT48ZUrPS5SNf/rsrJTMcknbKFJTtWL+ic2DCe/HcLMZIVXMIyOZwQRq0hjvU aYF+hta3iFsLHB5onz3BrN/giDITecVM4IsE8cJhznQv1ZVrv6JjDjEsajHesB7lL5Ej 6yXAWe4rDPrPJ0xigVLaKfH0v0woQ82OZ58syGwNAF4m4oy+YZiDZ32RnIcdr0OhnXUa P85Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cy3MpUtv+dRO9JK5z8XYxdENRpbwChC8f/DLqUKE5MI=; b=nnoffLnK0G/TnMEusTfUjlqvbu03WJjdoDkKd3lbAl0Ih8PObAUrc07PRAVH/s7MKp iShuaXYqMI7b5GlADtw+MUkbv9i8909QyOQMHMKAEmpcnRKagsrclS6+AbJqedLGV+El jK7e/OoCLRHmE/w4FY55D1tADPo8CiNFitmFW8AixURf0ZidiQqNLNFXuaMAH83wFd80 g3uajE4m3nm7X4wDqXa8qguiWGR+85ggpLbg7ZldysCdYZK2Ir9bcjd6W6Oo9v/djrPF 4ZNp3FwejlsO89JsqThe0jDfG7YS37qc6VEo+TK88gs/SjDdC57BpnZEQtuo6wDY2zdK JukA== X-Gm-Message-State: AO0yUKWkQmhzOCiwSDnncXMAV5HuMyQjTFBG4BKheRw6VHF4N7ofTRMg WytLdoy7hRFYEqUMklzXN2YfRflpgAeOA6m0/jc= X-Google-Smtp-Source: AK7set+pu7XeDe0s2iRE5l6U9AeOz42MdXJg9NJLucPsisItpYcE9vv8eAPvyzJKINEf6BFDbf8yXvDfD+9rdIK/SA0= X-Received: by 2002:a17:906:b751:b0:8b1:780d:e43d with SMTP id fx17-20020a170906b75100b008b1780de43dmr2041784ejb.13.1676643047868; Fri, 17 Feb 2023 06:10:47 -0800 (PST) MIME-Version: 1.0 References: <8ed6d28c-69dc-fed8-5ab5-99f685f06fac@gmail.com> <38e7e994a81d2a18666404dbaeb556f3508a6bd6.camel@redhat.com> In-Reply-To: From: Jonathan Wakely Date: Fri, 17 Feb 2023 14:10:35 +0000 Message-ID: Subject: Re: Missed warning (-Wuse-after-free) To: Siddhesh Poyarekar Cc: David Malcolm , Alejandro Colomar , GCC , Iker Pedrosa Content-Type: multipart/alternative; boundary="000000000000488c9005f4e5e1e2" X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,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: --000000000000488c9005f4e5e1e2 Content-Type: text/plain; charset="UTF-8" On Fri, 17 Feb 2023, 12:53 Siddhesh Poyarekar, wrote: > On 2023-02-17 06:24, Jonathan Wakely wrote: > > Please be aware that in C++ it's implementation-defined, not undefined. > > > > That means that an implementation without trap representations for > > pointers can choose to make it behave just like using (uintptr_t)p. > > > > https://cplusplus.github.io/CWG/issues/1438.html > > > > https://cplusplus.github.io/CWG/issues/623.html > > > > https://cplusplus.github.io/CWG/issues/616.html > > > > https://cplusplus.github.io/CWG/issues/312.html > > > > > > We could still warn in C++ (because the code isn't portable) but I would > > strongly suggest we don't influence C++ codegen based on deallocated > > pointers being undefined. I don't think gcc supports any targets with > > trapping pointers, and there are quite enough sources of UB already. We > > don't need to create traps for users where there are no traps for > > pointers :-) > > The codegen problem is a pointer provenance issue and AFAICT, > -Wuse-after-free=3 is also framed in that context and not as a problem > with simply taking the numeric value of the pointer to, e.g. log it > somewhere. > > More concretely, something like this is what causes problems: > > Foo *old = malloc (sz); > ... > Foo *new = realloc (old, newsz); > > if (new != old) > { > old = new; > /* Adjust references. */ > } > > /* Otherwise continue using old unchanged */ > ... > > The problem is the assumption that the old pointer continues to be valid > because it has the same numeric value as the new one. This is not an > uncommon code pattern in C, what about C++? > Nobody uses realloc in C++. It's only safe for trivial types, because anything with user-defined construction/assignment/destruction can't be copied to a new location if the memory is reallocated. > On a fat pointer-like scheme such as the Arm Morello cpu, this won't > work at all because even though old and new have the same numeric > values, old will have been invalidated. > > Sid > --000000000000488c9005f4e5e1e2--