> On Jul 25, 2025, at 11:27 AM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
>
> 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.
>

If you want an invalid address, just allocate one.

That’s all you need to do. You don’t need special language or compiler support. We already get into enough difficulty with the single magic invalid pointer we do have, why would adding more help?

If you decide carte blanche “0xbadbeef” must be an invalid pointer you’ve literally just made large allocations impossible on 32 bit machines by fracturing the address space.

—Oliver