2 ms·
Unfortunately the problem with that approach is contained in the sentence "since if [a pointer] is null [the] program will most likely crash which serves the pu
by orclev 13y ago
Unfortunately the problem with that approach is contained in the sentence "since if [a pointer] is null [the] program will most likely crash which serves the purpose of the assertion". It's that most likely part, you can't count on that, and in the case of a malicious actor if they can figure out a way to control the declaration of the null pointer (and yes, there are ways of doing this) you could be looking at an arbitrary code execution vulnerability.
There's also the fact that a program crashing is quite often not considered an acceptable way to handle an error condition (it is true however that a crash from a null de-reference vs. a crash from a failed assertion is, aside from security implications, functionally identical). In a large code base, if values default to null or even intentionally return null, it can be very difficult to track down and handle every single case, particular if someone changes something way down in the guts of some function that changes a pointer in a data structure to a null, but that pointer never gets accessed until you're in some completely different area of code. Sure you can handle the null in the location it causes a failure at, but what if what you really want to do is figure out where the null came from and prevent it from being null in the first place?
There's also the added advantage that adding extra effort to allow a value to be null is a nice subtle encouragement to not allow null values if possible in the first place.