home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c      Meh, in C you gotta define EVERYTHING      243,242 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 242,754 of 243,242   
   Andrey Tarasevich to highcrew   
   Re: NULL dereference in embedded [was: O   
   03 Jan 26 17:24:54   
   
   From: noone@noone.net   
      
   On Sat 1/3/2026 3:25 PM, 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?   
      
   Well, the first question would be: what is the physical null pointer   
   representation in that C implementation on that embedded system?   
      
   Null pointer in C is represented by an integer constant `0` at source   
   code level only (!). The actual physical representation in the compiled   
   code is not necessarily "address 0", contrary to popular misguided   
   belief. It can be anything. It is typically supposed to be chosen as   
   some appropriate "invalid address value" on the given platform.   
      
   The compiler on that embedded system is, of course, aware of the fact   
   that address 0x00000000 is perfectly valid and should be left   
   accessible. So, for that reason, the compiler is supposed to choose some   
   other physical representation for null pointers, like, say, address   
   0xFFFFFFFF (just for one example). So, every time you write something like   
      
      int *p = 0;   
      
   the compiler will emit code that stores `0xFFFFFFFF` into `p`.   
      
   In than implementation you will have no problem accessing address   
   0x00000000. No UB. No problem.   
      
   But if even under such circumstances the compiler decided to use address   
   0x00000000 for physically representing null pointers (say, for some   
   other important reasons)... well, then I guess the compiler will have no   
   other choice but to extend the formal language specification and   
   postulate that null pointer access is well-defined. There will be no   
   optimizations based on UB associated with null pointer access. At least   
   in some circumstances. That all would become implementation-defined, of   
   course.   
      
   --   
   Best regards,   
   Andrey   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca