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,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