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