Timeline for When should pointers be checked for NULL in C?
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 1, 2023 at 20:46 | comment | added | gnasher729 | @JohnR.Strohm I haven’t seen a “crash dump” that would be much different from hitting a breakpoint in the debugger for ages. | |
| Feb 22, 2020 at 6:25 | comment | added | John R. Strohm | @gnasher729: No, you want to detect the error so you can provide easily-understandable debug information, about which pointer was NULL and where it was. This will always be easier to debug with than a crash dump, if you are lucky enough to get as much as a crash dump. You do not want it to crash and burn. You ESPECIALLY do not want it to crash and burn while it is running the end-of-the-month production cycle, as that is just about guaranteed to get you fired instantly. | |
| Feb 21, 2020 at 22:00 | comment | added | gnasher729 | John: I want the program to crash and then I fix the problem. | |
| Jul 15, 2018 at 18:37 | comment | added | John R. Strohm | @gnasher729, if by "processor" you mean hardware and by "assert", you mean "crash", well, yeah, that's sort of the problem. You don't WANT the program to crash and force you to debug a crash dump (if you got that much). | |
| Jul 15, 2018 at 12:25 | comment | added | gnasher729 | Most processors assert anyway when you dereference a null pointer. | |
| Feb 6, 2013 at 22:33 | comment | added | detly | @JohnR.Strohm - this is C, it's assertions or nothing :P | |
| Feb 6, 2013 at 10:30 | comment | added | John R. Strohm | @James: The problem with error codes is that programmers almost never bother to check them. Throwing an exception or tripping an assert FORCES them to deal with the problem. | |
| Feb 6, 2013 at 10:28 | comment | added | John R. Strohm | @detly: If you are in a function that requires a non-NULL pointer, and you don't have a mechanism to return a fatal error to the caller, you throw an exception or trip an assert. I personally prefer throwing an exception, as that pretty much guarantees a traceback with the crash-and-burn. (I caught a lot of static on this some years ago, on an Ada project. I had to educate several people, including my manager, on the concept of policy/mechanism separation.) | |
| Feb 6, 2013 at 3:09 | comment | added | detly | @James - I meant that if you're changing an existing function just to validate input, changing the range and meaning of output values is (of course) not a good idea. | |
| Feb 6, 2013 at 2:58 | comment | added | James | @detly you're not going to get very far as a C dev if you don't like error codes | |
| Feb 6, 2013 at 2:55 | comment | added | detly |
@James - didn't think of assert, sure. I don't like the error code idea if you're talking about changing existing code to include NULL checks though.
|
|
| Feb 6, 2013 at 2:54 | comment | added | James | @detly either stop what you're doing and return an error code, or trip an assert | |
| Feb 6, 2013 at 2:05 | comment | added | Scott Wales | Checking malloc for NULL isn't always enough- for example Linux will happily overallocate memory, returning a non-NULL address, and leave it for the out of memory killer to deal with it. | |
| Feb 6, 2013 at 1:34 | comment | added | detly | If you're in a function that requires a non-NULL pointer, but you check anyway and it's NULL... what next? | |
| Feb 6, 2013 at 0:09 | history | answered | John R. Strohm | CC BY-SA 3.0 |