Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Comments on Should I check if pointer parameters are null pointers?
Parent
Should I check if pointer parameters are null pointers?
When writing any form of custom function such as this:
void func (int* a, int* b)
Should I add code to check if a and b are null pointers or not?
if(a == NULL)
/* error handling */
When posting code for code reviews, one frequent comment is that such checks against null should be added for robustness. However, these reviewers are then just as often corrected by others telling them to not add such checks because they are bad practice.
What should be done? Is there an universal policy to check or not to check, or should this be done on case-to-case basis?
Post
As with most everything in engineering, how much call arguments to a subroutine should be validated is a tradeoff. There is no single universal right answer. Note that checking for null pointers is only one instance of validating information from elsewhere before acting on it.
Advantages of data validation:
- Helps during development and debugging.
- Protects against possible malicious use.
- Reduces cascading errors. When everything is a mess, it's often hard to figure out what initially went wrong.
- Allowing bad data to pass may cause a hard failure later and crash the whole system. Trying to dereference a NIL pointer will usually crash a program. At that point, it can't apply any corrective action. However, if a NIL pointer is detected, then there is opportunity to handle the error without disrupting other parts of the operation.
- There might be legitimate reasons data could be invalid. Your subroutine might be the right place to check for that.
- Some errors can cause correct-looking results. Getting wrong answers can be far worse than the process stalling and giving no answer.
- Safety-critical applications. "Invalid message received about adjusting the control rods" may be preferred over "Raise the control rods by 1038 meters".
Of course nothing is free. Data validation comes at the cost of larger code size and slower run-time response. Whether that is a worthwhile tradeoff depends on a number of parameters:
- Does the extra delay in responsiveness matter? In critical control applications, it might.
- Does the extra code space matter? If it's in a high-volume throw-away consumer product that maxxes out a cheap microcontroller, then using the next size up micro may make the whole product non-viable.
- What's the cost of failure? Misreading a button press on a child's toy versus on an x-ray cancer treatment machine have vastly different downsides.
- How likely is bad data? Something a user types in could be anything, whereas the reading from your 10 bit A/D is always going to be 0-1023. Also, at some point data needs to be trusted. Is this a low level routine that should only be handed good data that has already been validated by upper layers?
- Is there anything you can do about it? On an embedded microcontroller there may be no operating system, no user console to write messages to, etc. In the end, your not really going to output 1038 volts. Resetting the system may be worse than the disruption due to a bad data value.
Everything is a tradeoff.
1 comment thread