C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Standardising 0xdeadbeef for pointers

From: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
Date: Fri, 25 Jul 2025 19:27:45 +0100
On Friday, July 25, 2025, Oliver Hunt wrote:

>
> > Not really. There isn't a computer in existence today -- I don't think
> > -- that uses more than 49 bits for a memory address. 64-Bit ARM uses
> > 48 bits but it can be extended by 1 bit to 49 bits.
> >
> > So you can mark a pointer as 'bad' by manipulating the top 15 bits. Or
> > even just set the top bit high.
>
> This is nonsense.
>
> High bits are 100% valid on numerous platforms.
>
> Numerous platforms make use of the high bits: CHERI, ARMv8.3 with PAC
> extensions, MTE, etc
>
> In addition to that many OS’s use high bits in kernel addresses. e.g
> 0x111….. is kernel space, 0x0000…. is user space.
>



Gonna make an attempt at deductive reasoning here.

Computers nowadays have 32-Bit or 64-Bit pointers. Some microcontrollers
have 8-Bit or 16-Bit pointers.

Talking about 64-Bit pointers . . . if each individual increment is one
8-Bit byte, then a 64-Bit pointer can address 18 million terabytes.

But nobody has that much memory. ARM uses at most 49 bits for memory, and I
think x86 goes up to 52 bits. So there are high bits wasted.

You're talking about stuff like ARMv8.3 with PAC extensions, but they're
not pointers. They're an encrypted datum. And just because you need 64 bits
to encrypt your 49-bit pointer, doesn't mean that the pointer is 64-Bit.

And if you have a tagged pointer with 4 bits used for something special,
you don't all of a sudden have a 53-Bit pointer -- you have a 49-Bit
pointer stored in a 64-Bit space along with an additional 4-Bit datum.

I'm talking about _pointers_ in this thread, not about the different kinds
of datum units you get when you encrypt pointers or mix them with other
unrelated datum units.

I'm just thinking now . . . maybe 'badptr' doesn't need to be a
compile-time constant. If the program starts executing with a base address
of 0x0000ca7687208900, then maybe in '_start', 'badptr' could be set to
half the base address. Guaranteed segfault outside the process's address
range. And the debugger would check the segfault address, and if it's near
enough to (base_addr / 2), then it would say 'Dereferencing of a badptr'.

Received on 2025-07-25 18:27:48