https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110619
Peter Cordes <peter at cordes dot ca> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |peter at cordes dot ca
--- Comment #7 from Peter Cordes <peter at cordes dot ca> ---
(In reply to Andrew Pinski from comment #2)
> >but it is not nullptr.
>
> 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 pointer
> value to a deallocation function have undefined behavior.
> **Any other use of an invalid pointer value has implementation-defined
> behavior.**
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 maybe
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.
