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,779 of 243,242    |
|    David Brown to James Kuyper    |
|    Re: NULL dereference in embedded [was: O    |
|    05 Jan 26 09:07:16    |
      From: david.brown@hesbynett.no              On 04/01/2026 19:00, James Kuyper wrote:       > On 2026-01-03 23:52, Lawrence D’Oliveiro wrote:       >> On Sat, 3 Jan 2026 21:31:20 -0500, James Kuyper wrote:       >>       >>> On 2026-01-03 21:19, Lawrence D’Oliveiro wrote:       >>>>       >>>> What if the entire machine address space is valid? Are C pointer       >>>> types supposed to add an extra “invalid” value on top of that?       >>>       >>> Either that, or set aside one piece of addressable memory that is       >>> not available to user code. Note, in particular, that it might be a       >>> piece of memory used by the implementation of C, or by the operating       >>> system. In which case, the undefined behavior that can occur as a       >>> result of dereferencing a null point would take the form of messing       >>> up the C runtime or the operating system.       >>       >> “Undefined behaviour” could also include “performing a valid memory       >> access”, could it not.       >       > Of course. In fact, the single most dangerous thing that can occur when       > code with undefined behavior is executed is that it does exactly what       > you incorrectly believe it is required to do. As a result, you fail to       > be warned of the error in your beliefs.              I don't think that is the most dangerous thing that could happen with       UB. Code that works as you expected during testing but fails after       deployment is much worse. If the UB always results in the effect you       intended, then the generated object code is correct for the tasks - even       if the source code is unknowingly non-portable.              And sometimes - especially in low-level embedded programming - getting       the effect you want with the efficiency you want means knowingly writing       code that has UB as far as C is concerned, but which results in the       desired object code. Such code is inherently non-portable, but so is a       lot of low-level embedded code. And you need to check the generated       object code carefully, document it well, comment it well, and add any       compile-time checks you can for compiler versions and other protection       against someone re-using the code later without due consideration.              --- 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