If a function argument can be null, but is never supposed to be null, you have three choices: a. You ignore this and whatever happens, happens. B. You check and if the pointer is null you report an error, throw an exception, kill the program, whatever seems most appropriate. C. You check and if the pointer is null you muddle through as best as you can. C. would likely be called “defensive programming”
You decide on a case-by-case basis what to do. Usually you look at it from a higher level where you decide “if this pointer, which should never be null, ends up being null, what’s the best thing to do”. During development the best would often be to fall into the debugger so the developer can figure out why the pointer is null and fix the problem. In production you need to decide intelligently what to do. In many situations it’s better for a program to crash than to give wrong results.
PS. In C++, a null reference is undefined behaviour. For example "int* p = NULL; int& r = *p;". Since it is undefined behaviour, checking that an int& reference that your function received is a null reference won't necessarily work. The compiler can say "null references are undefined behaviour, therefore there are no null references, therefore a check if (&r == NULL) is assumed to always fail". In Java, references to objects can be nil so you can check for it.
Xcode + Clang in C and C++ have an interesting feature: Since they don't know if a pointer argument is allowed to be a null pointer or not, they assume that the caller passed in a non-null pointer to avoid gazillions of warnings. But once you check whether it is null, the compiler assumes it can be null (or why would you have checked?) So
if (p == NULL) printf ("Error, p is null\n");
*p = 1;
will give you a warning. Without the p == NULL check, no warning.
