The usual strategy is to set nullptr to 0 and the microcontroller itself sees all addresses including 0 as fully valid, whereas C/C++ and user applications are a bit more careful, what resides there.   E.g. if it is an entry point to a interrupt routine, then the implementation and the programmer have to be aware that it can reside at address 0.   Not sure whether that is 100% standard compliant or whether an implementation can use its leeway to make it compliant on that platform. At least the implementation can make it work in practice, as long as only special objects reside there and no pointers to it are used.   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:So 03.08.2025 05:49 Betreff:Re: [std-proposals] Standardising 0xdeadbeef for pointers An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; On Saturday, August 2, 2025, David Brown wrote: There are microcontrollers supporting C++ with 16-bit pointers where there are /no/ invalid pointers - all are valid.    I think we should be focusing on this example for a minute.  So let's say we have a Harvard Architecture microcontroller, with code memory (non-volatile) separate from data memory (volatile), and let's say it has 65 kilobytes of SRAM.  If address 0 is accessible in the SRAM, then there's three viable strategies: (1) Make nullptr == 0xffff (2) Make nullptr == 0xfffe (3) Make nullptr == 0x0000, but before any pointer is dereferenced, subtract 1 from it.  With strategy No. 3, a pointer would have the bit pattern 0x0001 in order to access address 0.  Next question then is: If you want to identify the last byte as a range, i.e. [begin,end) , then will the end pointer be the same as the nullptr? If this must be avoided then it seems like 1 byte in the SRAM must be inaccessible from the C++ programming language. Unless it were to be stipulated that the end pointer might be equal to a null pointer.  And then what happens if we introduce badptr? Will badptr be given the bit pattern 0xFFFF? Subtracting 1 from it would give 0xFFFE -- but maybe that subtraction should never take place if the operand is 0xFFFF. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals