Frederick,

I know that references can't be EXPLICITLY set to nullptr. Could something
like this be used to say that INTERNALLY references are set to nullptr or
0xdeadbeef, even in production, to ensure that we get a segfault if the
memory hasn't been overwritten?


On Fri, Jul 25, 2025 at 7:17 AM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:

> I'm writing some code at the moment, and the destructor looks like this:
>
> ~Governor(void) noexcept
> {
> try
> {
> delete this->p;
> }
> catch(...){}
>
> this->p = (void*)0xdeadbeef;
> }
>
> I've set the pointer to 0xdeadbeef because I want to make sure that
> there's nowhere else in the code that this particular object gets
> deleted. If another part of the code goes to delete the object a
> second time, it will segfault on 0xdeadbeef -- which is exactly what I
> want to happen because I want the debugger to catch it.
>
> If alternatively I were to do:
>
> this->p = nullptr;
>
> then a double-delete won't be caught by the compiler because "delete
> nullptr" is harmless.
>
> We already have "nullptr_t", but what if we also had "badptr_t" and
> the constant expression "badptr"?
>
> So my destructor would become:
>
> ~Governor(void) noexcept
> {
> try
> {
> delete this->p;
> }
> catch(...){}
>
> this->p = badptr;
> }
>
> "badptr" coould be a pointer with all bits set to 1 (instead of
> 0xdeadbeef). I think it should be more elaborate than this though, and
> I'll explain why. I remember I was assigned a bug at work one time, a
> program was segfaulting because the memory address 0xFFFFFFFE was
> being accessed inside "libc". It turns out that the code did this:
>
> char *p = std::strchr( str, 'Z' ) - 2;
> strcpy( str2, p );
>
> The call to 'strchr' was failing to find the letter 'Z', and so it
> returned a nullptr. But then the nullptr got 2 subtracted from it,
> giving 0xFFFFFFFE. So then the implementation of "std::strcpy" inside
> "libc" was segfaulting on accessing memory address 0xFFFFFFFE.
>
> This is the reason why I think "nullptr" and "badptr" should be far
> away from each other -- it's not good enough to be able to
> increment/decrement one of them to get the other.
>
> And I suppose I might be running the risk in my own program running on
> x86_64 that 0xdeadbeef could be a valid address. Maybe make sure the
> top bit is high: 0xdeadbeefdeadbeef.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>