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