From: david.brown@hesbynett.no   
      
   On 04/01/2026 16:51, Scott Lurndal wrote:   
   > James Kuyper  writes:   
   >> On 2026-01-03 18:25, highcrew wrote:   
   >>> On 1/4/26 12:15 AM, highcrew wrote:   
   >>>> I have a horrible question now, but that's for a   
   >>>> separate question...   
   >>>   
   >>> And the question is:   
   >>>   
   >>> Embedded systems.  Address 0x00000000 is mapped to the flash.   
   >>> I want to assign a pointer to 0x00000000 and dereference it to   
   >>> read the first word.   
   >>> That's UB.   
   >>   
   >> Actually, that's not necessarily true. A null pointer is not required to   
   >> refer to the location with an address of 0. An integer constant   
   >> expression with a value of 0, converted to a pointer type, is guaranteed   
   >> to be a null pointer, but that pointer need not have a representation   
   >> that has all bits 0. However, an integer expression that is not a   
   >> constant expression, if converted to a pointer type, is not required to   
   >> be a null pointer - it could convert to an entirely different pointer value.   
   >>   
   >> So an implementation could allow it simply by reserving a pointer to   
   >> some other location (such as the last position in memory) as the   
   >> representation of a null pointer.   
   >>   
   >>> How do I?   
   >>   
   >> Even on an implementation that uses a pointer representing a machine   
   >> address of 0 as a null pointer, such code can still work. In the C   
   >> standard, "undefined behavior" means that the C standard imposes no   
   >> requirements on the behavior. That doesn't prohibit other sources from   
   >> imposing requirements. On such a system, it could define the behavior as   
   >> accessing the flash.   
   >   
   > Indeed, every C compiler I've ever used has simply dereferenced a   
   > pointer that has a value of zero.   In user mode, the kernel will   
   > generally trap and generate a SIGSEGV or equivalent.  In kernel   
   > mode, it will just work, assuming that the CPU is configured to   
   > run with MMU disabled (or the MMU has a valid mapping for virtual   
   > address zero).   
   >   
      
   The context (embedded systems with flash at address 0) implies you don't   
   have signals, an MMU, or other "big OS" features.  While embedded   
   systems over a certain size usually have some kind of memory protection   
   unit, and interrupts/traps/exceptions for address or bus errors, you can   
   be very confident that these will not trigger on attempts to read from   
   address 0 if that is part of the normal code address area - the   
   protection systems are not that fine-grained.  (You might, while trying   
   to catch a bad pointer bug, put a read watchpoint at address 0 in your   
   debugger.)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)