Take the 2-minute tour ×

Most people use pointers like this...

if ( p != NULL ) {

However, if the pointer is null for whatever reason, the function won't be called.

My question is, could it possibly be more beneficial to just not check for NULL? Obviously on safety critical systems this isn't an option, but your program crashing in a blaze of glory is more obvious than a function not being called if the program can still run without it.

In relation to the first question, do you always check for NULL before you use pointers?

Secondly, consider you have a function that takes a pointer as an argument, and you use this function multiple times on multiple pointers throughout your program. Do you find it more beneficial to test for NULL in the function (the benefit being you don't have to test for NULL all over the place), or on the pointer before calling the function (the benefit being no overhead from calling the function)?

share|improve this question
Most people do look around before crossing the street to find out if they might be hit by an incoming car. But that's not strictly necessary, you can find out if you are going to be hit by a car by simply crossing the street. :-) –  Franci Penov Dec 17 '09 at 5:30
@Franci: most people check for cars, and while cars are there, wait. Many programs check for cars, and if cars are there, jump to the next zebra crossing. –  xtofl Dec 17 '09 at 8:41
I prefer to avoid this problem by passing-by-reference whenever possible. –  Steve Guidi Dec 17 '09 at 15:48
@Steve and others. Obviously that's ideal, but it isn't always an option. –  trikker Dec 17 '09 at 18:07

13 Answers 13

up vote 5 down vote accepted

Don't make it a rule to just check for null and do nothing if you find it.

If the pointer is allowed to be null, then you have to think about what your code does in the case that it actually is null. Usually, just doing nothing is the wrong answer. With care it's possible to define APIs which work like that, but this requires more than just scattering a few NULL checks about the place.

So, if the pointer is allowed to be null, then you must check for null, and you must do whatever is appropriate.

If the pointer is not allowed be null, then it's perfectly reasonable to write code which invokes undefined behaviour if it is null. It's no different from writing string-handling routines which invoke undefined behaviour if the input is not NUL-terminated, or writing buffer-using routines which invoke undefined behaviour if the caller passes in the wrong value for the length, or writing a function that takes a file* parameter, and invokes undefined behaviour if the user passes in a file descriptor reinterpret_cast to file*. In C and C++, you simply have to be able to rely on what your caller tells you. Garbage in, garbage out.

However, you might like to write code which helps out your caller (who is probably you, after all) when the most likely kinds of garbage are passed in. Asserts and exceptions are good for this.

Taking up the analogy from Franci's comment on the question: most people do not look for cars when crossing a footpath, or before sitting down on their sofa. They could still be hit by a car. It happens. But it would generally be considered paranoid to spend any effort checking for cars in those circumstances, or for the instructions on a can of soup to say "first, check for cars in your kitchen. Then, heat the soup".

The same goes for your code. It's much easier to pass an invalid value to a function than it is to accidentally drive your car into someone's kitchen. But it's still the fault of the driver if they do so and hit someone, not a failure of the cook to exercise due care. You don't necessarily want cooks (or callees) to clutter up their recipes (code) with checks that ought to be redundant.

There are other ways to find problems, such as unit tests and debuggers. In any case it is much safer to create a car-free environment except where necessary (roads), than it is to drive cars willy-nilly all over the place and hope everybody can cope with them at all times. So, if you do check for null in cases where it isn't allowed, you shouldn't let this give people the idea that it is allowed after all.

[Edit - I literally just hit an example of a bug where checking for null would not find an invalid pointer. I'm going to use a map to hold some objects. I will be using pointers to those objects (to represent a graph), which is fine because map never relocates its contents. But I haven't defined an ordering for the objects yet (and it's going to be a bit tricky to do so). So, to get things moving and prove that some other code works, I used a vector and a linear search instead of a map. That's right, I didn't mean vector, I meant deque. So after the first time the vector resized, I wasn't passing null pointers into functions, but I was passing pointers to memory which had been freed.

I make dumb errors which pass invalid garbage approximately as often as I make dumb errors which pass null pointers invalidly. So regardless of whether I add checking for null, I still need to be able to diagnose problems where the program just crashes for reasons I can't check. Since this will also diagnose null pointer accesses, I usually don't bother checking for null unless I'm writing code to generally check the preconditions on entry to the function. In that case it should if possible do a lot more than just check null.]

share|improve this answer
I've slightly rethought the matter after sleeping on it. Due to the nature of the program, pointers are never supposed to be NULL under any circumstances. However, checking for NULL can be useful under circumstances in which the programmer failed to initialize the pointer to the correct value or did something dumb like ( if p = NULL ). Just seeing the program crash isn't terribly helpful, so printing a message when this occurs seems ideal (only in debug mode). –  trikker Dec 17 '09 at 15:01
"Just seeing the program crash isn't terribly helpful" - it usually is, if you run your tests under a debugger. But depending on your platform, you might not have a debugger available. And you might not always use it even if it is there. So I think switch-on-and-offable checks, such as assert, are useful –  Steve Jessop Dec 17 '09 at 15:33
If my program crashes, I generally do a a glance through of what I believe the potential problem to be. If I can't find anything, or I'm dead wrong, I go to the debugger. However, a message saying "null pointer error" would certainly make that search a lot easier because I'd know what to look for. –  trikker Dec 17 '09 at 18:08

You are right in thinking that NULL pointers often result in immediate crashes, but do not forget that if you are indexing into a large array through a NULL pointer, you might indeed get a valid memory address if your index is high enough. And then, you'll get memory corruption or incorrect memory reads, which will be much harder to locate.

Whenever I can assume that calling a function with NULL is a bug, which should never happen in production code, I prefer using ASSERT guards in the function, which are only compiled into real code in a debug build, and not checking for NULL otherwise.

And from my point of view, generally, a function should check its arguments, not the caller. You should always assume that your callers might have been a bit sloppy about the checking, or that they might contain bugs...

Morality: check for NULL in the function being called, either through some if() statement that throws, or using some ASSERT construct (possibly with a clear message of why this happened). Also check for NULL in the callers, but only if the callers know that this condition might happen in a normal program execution, and act accordingly.

share|improve this answer
After wish washing it in my head for awhile, I finally came to the conclusion that, calling a function on a null pointer leads to undefined behavior, and even if it causes the program to crash in a blaze of glory, it's an undefined blaze of glory. I'd rather check for null than do that. –  trikker Dec 17 '09 at 5:46

When it's acceptable for the program to just crash if a NULL pointer comes up, I'm partial to:


This will only check the pointer in debug builds since defining NDEBUG usually #undefs assert() at the preprocessor level. It documents your assumption and assists with debugging but has zero performance impact on the released binary (though, to be fair, checking for a NULL pointer should have effectively zero impact on performance in the vast majority of circumstances).

As a side benefit, this is legal for C as well as C++ and, in the latter case, doesn't require exceptions to be enabled in your compiler/runtime.

Concerning your second question, I prefer to put the assertions at the beginning of the subroutine. Again, the beauty of assert() is the fact that there's really no 'overhead' to speak of. As such, there's nothing to weigh against the benefits of only requiring one assertion in the subroutine definition.

Of course, the caveat is that you never want to assert an expression with side-effects:

assert(p = malloc(1)); // NEVER DO THIS!
DoSomethingWithP();    // If NDEBUG was defined, malloc() was never called!
share|improve this answer
The problem with assert is that it causes additional delay in debug mode. Thus, the timing is not the same as in release build. Especially in real time applications, if you have many asserts the whole program may stop working. –  PauliL Dec 17 '09 at 9:40
True; I was working with some code that did something like assert(ValidGraph(g)); where ValidGraph() was some expensive routine that checked a whole lot of characteristics of the graph. This was called inside a loop and resulted in an unusably slow debug version (and this application was not real-time). –  mrkj Dec 17 '09 at 14:15
assert() is no panacea, but I believe it's an attractive solution in a lot of common, realistic instances. –  mrkj Dec 17 '09 at 14:17
"The problem with assert is that it causes additional delay in debug mode. Thus, the timing is not the same as in release build. Especially in real time applications, if you have many asserts the whole program may stop working" --- if you rely on your debug build performing the same as relase build, you're doing it wrong. STL is often WAY slower in debug mode and this is typical in 3rd-party libs. –  Mr. Boy Dec 17 '09 at 16:38

I prefer this style:

if (p == NULL) {
    // throw some exception here


This means that whatever function this code lives in will fail quickly in the event that p is NULL. You are correct that if p is NULL there is no way that DoWhateverWithP can execute but using a null pointer or simply not executing the function are both unacceptable ways to handle the fack the p is NULL.

The important thing to remember is to exit early and fail fast - this kind of approach yields code that is easier to debug.

share|improve this answer
+1 for throwing exception. Exceptions make the code more readable and debug easier. –  Paulo Santos Dec 17 '09 at 5:21
-1 for throwing exceptions. Is it truly an exceptional circumstance, or is it a routine thing your code has to be able to deal with? –  mch Dec 17 '09 at 5:31
@mch, if the program has to be able to deal with it, then certainly, crashing is not an option. That's what is under discussion. –  Bahbar Dec 17 '09 at 9:00
@mch, yes, it's an exceptional circumstance. –  rpg Dec 17 '09 at 9:26

In addition to the other answers, it depends upon what NULL signifies. For example, this code is perfectly OK, and is pretty idiomatic:

while (fgets(buf, sizeof buf, fp) != NULL) {

Here, NULL value indicates not only error, but end-of-file condition as well. Similarly, strtok() returns NULL to say, "there are no more tokens" (although one should avoid strtok() to begin with, but I digress). In cases like this, it is perfectly OK to call a function if the returned pointer is not NULL, and do nothing otherwise.

Edit: another example, closer to what was asked:

const char *data = "this;is;a;test;";
const char *curr = data;
const char *p;
while ((p = strchr(curr, ';')) != NULL) {
    /* process data in [curr, p) */
    process(curr, p);
    curr = p + 1;

Once again, NULL here is an indication from strchr() that it couldn't find a ;, and that we should stop processing the data further.

Having said that, if NULL is not used as an indication, then it depends:

  • If the pointer can't be NULL at this point in code, it's useful to have an assert(p != NULL); when developing, and also having a fprintf(stderr, "Can't happen\n"); or equivalent statement, and then take whatever action as appropriate (abort() or similar is probably the only sane choice at this point).
  • If the pointer can be NULL, and it's not critical, it might be better to just bypass the usage of the null pointer. Suppose you're trying to allocate memory for writing a log message, and malloc() fails. You shouldn't abort the program because of this. If malloc() succeeds, you want to call a function (sprintf()/whatever) to fill the buffer.
  • If the pointer can be NULL, and it's critical. In this case, you probably want to fail, and hopefully such conditions don't happen too often.


This depends upon a lot of factors. If I can be sure sometimes or most of the times that the pointer passed to a function cannot be NULL, the extra check in the function is wasteful. If the pointer passed comes out of a lot of places, and it's tricky to put in a check everywhere, sure, then the check is good to have in the function itself.

The standard library functions, for the most part, don't check for NULL: str*, mem* functions for example. An exception is free(), it does check for NULL.

A comment about assert: assert is a no-op if NDEBUG is defined, so one should not use it for debugging—its only use is during development to catch programming errors. Also, in C89, assert takes an int, so assert(p != NULL) is better in such cases than a just plain assert(p).

share|improve this answer

How about: a comment clarifying the intent? If the intent is "this can't happen", then perhaps an assert would be the right thing to do instead of the if statement.

On the other hand, if a null value is normal, perhaps an "else comment" explaining why we can skip the "then" step would be in order. Stevel McConnel has a good section in "Code Complete" about if/else statements, and how a missing else is a very common error (distracted, forgot it?).

Consequently, I usually put a comment in for a "no-op else", unless it is something of the form "if done, return/break".

share|improve this answer

This non-NULLness check can be avoided by using references instead of pointers. This way, the compiler ensures the parameter passed is not NULL. For example:

void f(Param& param)
    // "param" is a pointer that is guaranteed not to be NULL      

In this case, it is up to the client to do the checking. However, mostly the client situation will be like this:

Param instance;

No non-NULLness checking is needed.

When using with objects allocated on the heap, you can do the following:

Param& instance = *new Param();

Update: As user Crashworks remarks, it is still possible to make you program crash. However, when using references, it is the responsibility of the client to pass a valid reference, and as I show in the example, this is very easy to do.

share|improve this answer
It's possible to have a reference that is null. For example, if I called int *foo =NULL; f(*foo);. This will compile and call into f, and then segfault on actually using the reference. –  Crashworks Dec 17 '09 at 8:32
You're wrong: param is not a pointer, it's a reference. –  Alok Singhal Dec 17 '09 at 8:35
@Crashworks: you are right, but that doesn't make much sense, does it? –  Dimitri C. Dec 17 '09 at 8:38
You only get a segmentation fault? You're lucky. When I run that code, demons fly out my nose! –  Rob Kennedy Dec 17 '09 at 8:39
@Crashworks: In these rare cases, I suggest you do the non-NULLness check in the client code. –  Dimitri C. Dec 17 '09 at 8:55

Well the answer to the first question is: you are talking about ideal situation, most of the code that I see which uses if ( p != NULL ) are legacy. Also suppose, you want to return an evaluator, and then call the evaluator with the data, but say there is no evaluator for that data, its make logical sense to return NULL and check for NULL before calling the evaluator.

The answer to the second question is, it depends on the situation, like the delete checks for the NULL pointer, whereas lots of other function don't. Sometimes, if you test the pointer inside the function, then you might have to test it in lots of functions like:

a = DEF(p);
d = GHI(a);
JKL(p, d);

but this code would be much better:

 a = DEF(p);
 d = GHI(a);
 JKL(p, d);
share|improve this answer

Could it possibly be more beneficial to just not check for NULL?

I wouldn't do it, I favor assertions on the frontline and some form of recovery in the body past that. What would assertions not provide to you, that not checking for null would? Similar effect, with easier interpretation and a formal acknowledgement.


It really depends on the code and the time available, but I am irritatingly good at it; a good chunk of 'implementation' in my programs consists of what a program should not do, rather than the usual 'what it should do'.

Secondly, consider you have a function that takes a pointer as an argument...

I test it in the function, as the function is (hopefully) the program that is reused more frequently. I also tend to test it before making the call, without that test, the error loses localization (useful for reporting and isolation).

share|improve this answer

I think I've seen more of. This way you don't proceed if you know it's going to blow up anyway.

if (NULL == p)
  goto FunctionExit; // or some other common label to exit the function.
share|improve this answer
Erm... Dijkstra wouldn't approve: u.arizona.edu/~rubinson/copyright_violations/… –  mrkj Dec 17 '09 at 5:20
I don't approve of C++ in the hands of mankind in general. This is just what I've seen in the wild... because he/she has been bitten by C++ so many times that he doesn't trust any incoming data... ever. So the same argument is checked at each step down the call chain. –  Gishu Dec 17 '09 at 5:24
Also maybe because exceptions are more work and more in your face :).. which is precisely what the authors wanted to avoid. –  Gishu Dec 17 '09 at 5:26
I think the common label is referred to as return; –  GManNickG Dec 17 '09 at 5:49
That's exactly what destructors and RAII are supposed to do. –  Crashworks Dec 17 '09 at 8:34

I think it is better to check for null. Although, you can cut down on the amount of checks you need to make.

For most cases I prefer a simple guard clause at the top of a function:

if (p == NULL) return;

That said, I typically only put the check on functions that are publicly exposed.

However, when the null pointer in unexpected I will throw an exception. (There are some functions it doesn't make any sense to call with null, and the consumer should be responsible enough to use it right.)

Constructor initialization can be used as an alternative to checking for null all the time. This is especially useful when the class contains a collection. The collection can be used throughout the class without checking whether it has been initialized.

share|improve this answer

Dereferencing a null pointer is undefined behavior. If you want to crash if the pointer is null, use an assert or something similar (and, depending on the defined behavior of your class, that can be a perfectly valid response - it's certainly better than continuing to run when people may be expecting something to have been done!).

Since the behavior of dereferencing a null pointer is undefined, it can do anything. Crash, corrupt memory, create a wormhole to an alternate dimension allowing the Elder Gods to come forth and devour all of mankind... anything. While bugs happen, depending upon undefined behavior is, by definition, a bug. So don't do it deliberately.

share|improve this answer

When you check for NULL, it is not good idea just to skip the function call. You should have an else-part that does something meaningful in case of NULL, for example throws an error or returns error code to upper level.

On the other hand, NULL is not always an error. It is often used to indicate for example that end of data has been reached. In such case, you will have to handle the situation as normal program flow.

share|improve this answer

Your Answer


