Date: Sun, 3 Aug 2025 14:34:14 +0200
On 03/08/2025 05:49, Frederick Virchanza Gotham via Std-Proposals wrote:
>
>
> 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.
That's an unrealistic example, but okay. (And surely you mean 64 KB ram.)
>
> 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.
>
None of these are remotely realistic or practical.
What actually happens is that null pointers are 0, just like on almost
all systems (except for a few obscure machines). Anything else would be
painfully inefficient and highly unexpected.
Programmers either understand that a pointer may be address 0 (and
compare equal to 0 and nullptr, and convert to bool false) while still
pointing to data, or simply avoid taking the address of data at address 0.
On such targets, compilers will typically disable optimisations based on
the knowledge that dereferencing a null pointer is UB (this is
controlled by "-fno-delete-null-pointer-check" in gcc).
>
>
> 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.
That's an unrealistic example, but okay. (And surely you mean 64 KB ram.)
>
> 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.
>
None of these are remotely realistic or practical.
What actually happens is that null pointers are 0, just like on almost
all systems (except for a few obscure machines). Anything else would be
painfully inefficient and highly unexpected.
Programmers either understand that a pointer may be address 0 (and
compare equal to 0 and nullptr, and convert to bool false) while still
pointing to data, or simply avoid taking the address of data at address 0.
On such targets, compilers will typically disable optimisations based on
the knowledge that dereferencing a null pointer is UB (this is
controlled by "-fno-delete-null-pointer-check" in gcc).
Received on 2025-08-03 12:34:20