This is a bad solution to the problem. Just use address sanitizer.

Cheers,
Jeremy

On Fri, Jul 25, 2025 at 05:17 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
>