From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9F78B3858284; Mon, 7 Aug 2023 05:04:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9F78B3858284 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1691384684; bh=MdC1sXN4eqcBG6pNp3S8TYkH7KXNasJs5mit3NlU8EA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=sK7+YmSq9dH7IbUqvDb/EleBFwmvTb9IzpB3XUnoM2RIJmjNd8Bc67cZJtwRR9kf/ 1ZsiRLfT9cdWFoxOO+3msQFYrC5ZSQgZ3Y0vOIAJzLr2rRpVp1n3wLK66V7WspHVaI knXENNRsdU4KuQXJykno6rou2+l2q6X4VFkiklGs= From: "peter at cordes dot ca" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/110619] Dangling pointer returned from constexpr function converts in nullptr Date: Mon, 07 Aug 2023 05:04:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 13.1.0 X-Bugzilla-Keywords: accepts-invalid, diagnostic, rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: peter at cordes dot ca X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110619 Peter Cordes changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |peter at cordes dot ca --- Comment #7 from Peter Cordes --- (In reply to Andrew Pinski from comment #2) > >but it is not nullptr. >=20 > Or is it just undefined so it could be considered a nullptr ... Implementation-defined behaviour, according to answers on https://stackoverflow.com/questions/76843246/why-does-the-address-of-an-out= -of-scope-variable-equal-zero-with-constexpr https://eel.is/c++draft/basic.compound#def:value,invalid_pointer https://eel.is/c++draft/basic.stc.general#4 > Indirection through an invalid pointer value and passing an invalid poin= ter value to a deallocation function have undefined behavior. > **Any other use of an invalid pointer value has implementation-defined be= havior.** So this wasn't a bug, but the new behaviour is also allowed. This commit could be reverted or kept, depending on maintainability and/or quality-of-life for users of GCC. Having it pick the other implementation-defined behaviour from clang (GCC's previous behaviour) is m= aybe a *good* thing, to help programmers catch dependence on an invalid pointer being either null or non-null if they try their code with both compilers.=