From: david.brown@hesbynett.no   
      
   On 04/01/2026 00: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.   
   >   
   > How do I?   
   >   
   > Now I guess that an embedded compiler targeting that certain   
   > architecture where dereferencing 0 makes sense will not treat   
   > it as UB.  But it is for sure a weird corner case.   
   >   
      
   There are some common misconceptions about null pointers in C.  A "null   
   pointer" is the result of converting a "null pointer constant", or   
   another "null pointer", to a pointer type.  A null pointer constant is   
   either an integer constant expression with the value 0 (such as the   
   constant 0, or "1 - 1"), or "nullptr" in C23.  You can use "NULL" from   
    as a null pointer constant.   
      
   So if you write "int * p = 0;", then "p" holds a null pointer.  If you   
   write "int * p = (int *) sizeof(*p); p--;" then "p" does not hold a null   
   pointer, even though it will hold the value "0".   
      
   On virtually all real-world systems, including all embedded systems I   
   have ever known (and that's quite a few), null pointers correspond to   
   the address 0.  But that does not mean that dereferencing a pointer   
   whose value is 0 is necessarily UB.   
      
   And even when dereferencing a pointer /is/ UB, a compiler can handle it   
   as defined if it wants.   
      
   I think that if you have a microcontroller with code at address 0, and a   
   pointer of some object type (say, "const uint8_t * p" or "const uint32_t   
   * p") holding the address 0, then using that to read the flash at that   
   address is UB.  But it is not UB because "p" holds a null pointer - it   
   may or may not be a null pointer.  It is UB because "p" does not point   
   to an object.   
      
   In practice, I have never seen an embedded compiler fail to do the   
   expected thing when reading flash from address 0.  (Typical use-cases   
   are for doing CRC checks or signature checks on code, or for reading the   
   initial stack pointer value or reset vector of the code.)  If you want   
   to be more confident, use a pointer to volatile type.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)