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,763 of 243,242   
   Lawrence =?iso-8859-13?q?D=FFOlivei to James Kuyper   
   Re: NULL dereference in embedded [was: O   
   04 Jan 26 21:22:57   
   
   From: ldo@nz.invalid   
      
   On Sun, 4 Jan 2026 13:00:02 -0500, 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.   
      
   In this case, it’s not clear what choice you have.   
      
   Call it a C language limitation ...   
      
   --- 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