Exception 0xD.
-- Your friendly x86 processor after a NULL pointer dereference

Introduction

Every now and then a discussion about NULL comes up. Much like operator overloading of multiplication of a geometric vector class. In the course of the discussion many questions and theories are covered, I'd like to give my views on them here in this short article.

Let me count the ways...

Let's do a quick recap of the ways we can express zero in the language:

All these things evaluate to 0, which is kind of funny.

Another bad thing is that given the following code you will never call foo(char*), and the compiler will do this without a warning because it knows that it found the best conversion to an int.

 void foo(int);
void foo(char*);

foo(NULL); // Gaaah, will call the wrong thing!

Given the situation, this is kind of confusing. The whole thing comes down to the difference between a null pointer value and a null pointer constant. The the former has a type given by the context, the latter is an integral expression, which basically means it's an int. That's why the above call will choose the integer overload instead of the char* one since the compiler doesn't need to convert to a pointer value from the pointer constant in order to match the second signature, the pointer constant will do just fine as an integer constant as well.

NULL, null, 0?

What should we use to indicate an invalid pointer? I can't help to feel that the null pointer is halfway in the language and halfway in the library implementation. Stroustrup & Sutter tries to remedy the fact and introduce the null pointer as nullptr properly into the language but it's not implemented yet. For now, it is still perfectly legal to just replace all the NULL instances with zeros. And it will still work, indeed it will be the exact same code since the definition of NULL is usually just a literal 0. For me personally I've converted to the practice to just use 0 instead of null, simply just because it's one less include as well as I don't get into any false assumptions that it is a pointer.

There is nothing in the language itself that prohibit the use of a literal 0 instead of NULL, actually if you look at most library implementations of NULL, they just translate into a 0.

 #define NULL 0

In closing

The bad part is that so much has been written about the simple thing as a null pointer (worse, I've added to the mess). It should not be that difficult. Indeed, in other languages like java and C#, there is a dedicated object for null. As in more script like languages as Lua and Python. Which is ironic, since the latter are dynamic typed, whereas C++ is statically and strongly typed. Except when it comes to null. Maybe the C++0x standard revision will bring sanity to the mix with nullptr. But they better hurry, or soon it will be C++1x. After the specification is release, we still have to wait for the compilers to catch up. Anyone remembered the lag it took for Visual Studio to become somewhat compliant (it still isn't of course)?







References

  1. Programming Language C++ [C++03] ISO/IEC 14882:2003(E)
  2. A name for the null pointer: nullptr Bjarne Stroustrup and Herb Sutter
  3. (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1601.pdf)
  4. Much ado about nothing Herb Sutter (http://www.ddj.com/cpp/184401802)

Comments