Apology of the NULL pointer

That is why I always initialize my pointers with random values

I must say, that the NULL (or 0) pointer is actually something quite useful.
Worse is the invalid pointer, as a null pointer is perfectly okay, its a not-valid-pointer.
One if you’re done. But the invalid Pointer will slip through this, and, give you quite a job to find him, if the debugger doesn’t track him down.
Also, if useful, you always should think about using smartpointers instead.
Their less risky, still even they can fail.

Wow, poor null pointer, made me cry.

0 is a hack at best. It is clearly an integer (or long, or long long, or other, but I digress) NULL is at least a /pointer/ to something, which is not in existence. Which itself is at least pointer. So at a minimum you know that you’re not working with something, but rather a variable pointing to no instance.

“Now I am nothing” – Trent Reznor.

I think it’s much better to use assert to check for null pointer, than to let software crash with silent segfault

Null pointer is like your conscience..listen it!

@JW: You are aware that the 0-pointer is not necessarily invalid, are you? 0 is a perfectly valid address, it is just a convention to have the kernel make sure that this page is never available (thus triggering a segfault when accessing anything in that page). There are ways to map data to this page though and some really interesting attacks on a linux system were possible due to this fact a while back.

Too bad Trolltech doesn’t it its own food (Qt doesn’t use smart pointers).

“Nobody likes me, everybody hates me, I’m going to let you make worms!”

(By the way, this is the third time I’ve tried to enter this. The first two CAPTCHAs were illegible, thanks to i/1 and O/0 ambiguity. There’s a perfectly good CAPTCHA system out there called reCAPTCHA – please consider using it.)

@KarlNapf :

[...]
6.3.2.3 Pointers
[...]
3 An integer constant expression with the value 0, or such an expression cast to type
void *, is called a null pointer constant.) If a null pointer constant is converted to a
pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal
to a pointer to any object or function.
[...]
6.5.3 Unary operators
4 The unary * operator denotes indirection. If the operand points to a function, the result is
a function designator; if it points to an object, the result is an lvalue designating the
object. If the operand has type “pointer to type”, the result has type “type”. If an
invalid value has been assigned to the pointer, the behavior of the unary * operator is
undefined.87)
[...]
NOTE 87: [...] Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer
[...]

(because my code in my previous comment did not render well: http://pastebin.com/JPxpLeWq )

Actually Qt objects use a QScopedPointer for their private implementation (using the pImpl idiom) internally. I guess not using them _everywhere_ is a performance trade-off?

@chalup
All disadvantages of pointers in C++ can also be applied to references. They can dangle and as a consequence they can be NULL. Consider the following:

QString* string = NULL;
test((*string));

with test as

void test(QString& test)
{
qDebug()

@chalup
All disadvantages of pointers in C++ can also be applied to references. They can dangle and as a consequence they can be NULL. Consider the following:

QString* string = NULL;
test((*string));

with test as

void test(QString& test)
{
qDebug() test;
}

this will crash inside qDebug() .

And you say using arguments for out paramaters in not very nice. Well what else could Qt do if there is more then one argument if it does not want to become a template beast like boost *shudders*?

“My mission is very simple: if I appear in your software it is not a sign that your software is badly designed, I’m just pointing out a case that was not considered before.”

I agree, the software is not badly designed – instead, it is the whole programming language in which the software is written. So, technically, you are right, the software is not to be blamed. We have been using badly designed programming language for sooo long that we simply got used to them, and forgot that type-safe high-performance languages in which the NULL pointer is *not* a nightmare are actually possible.

As a bonus, below is a C++ program which will compile just fine (by GCC), with a mere warning printed out. Who cares, just a warning. When one sees a compiler that is accepting obviously incorrect programs, the only conclusion that can be derived is that the designers of the language and of the compiler are TOTALLY INSANE people who have NO IDEA about programming language design.

int& fn() {
int i=10;
return i;
}

… the NULL pointer is not alone, in C/C++ it has many many friends.

… though I don’t actually expect the author of “Apology of the NULL pointer” to grasp this.

Wow, despite the fact that this is a controversial topic I didn’t expect this amount of replies. Specially not the ones attacking people because of what they say (and I don’t mean just the post by “*” which is a personal critic to my capabilities).
It is interesting to see that people are at least trying to have a discussion, and as the NULL pointer said, at least they are trying to answer to it. We have been told since the beginning of our programming days that NULL pointers are a bad idea. We have even shown examples of languages who manage to avoid the problem at all by controlling the memory for you and that is cool. However the point I was trying to make is simple, there are some situations where the only sensible thing to do is to let your application crash. Detecting a NULL pointer by introducing the classical:

{code}
if(!p) {
….. handle situation ….
}
{code}

might seem like a good idea, but there are situations where this will simply not work. Or to put it mildly, the consequences of stopping and handling the situation are worst than the consequences of just letting the app crash. For example, what can you do if you are deep inside a paint engine and you get a NULL pointer because you ran out of video memory? How are you going to continue on that situation? Just imagine the situation and you will realize that knowing that there is a NULL pointer gives you nothing because you still need to keep painting, and you will request more memory very shortly. Can you go back and tell whoever is requesting you to paint stuff to cool down and wait until the memory situation is solved? And by the way, who gives you any warranties that the situation is going to be fixed in the first place?
Now, please don’t come with the special cases where your application is handling a nuclear reactor and you cannot crash. That is a completely different story, and the way you will approach that will be very different. To begin with, you will avoid as much as possible the dependency on memory being available when you request it. Even more, you will have a redundant system to make sure that you can handle the situation if need arises. But in a normal application there is very little you can do, except crash or stop your application.
Finally, some clarifications. Memory it is a scarce resource and that is independent of the programming language you are using. There are very few programming languages that will offer any warranties on memory always being available when you request it. And that usually implies that you need to say at the beginning how much memory you will need, so the environment can reserve that memory for you and have it allocated and ready to be used. Even if the programming language does that, there is actually no warranties that the Operating System is going to provide that memory. In modern operating system it is a common practice to overcommit memory. I.e. accept as many memory requests as you can and only assign memory at the moment it is used. So even if the programming language runtime requested memory, it is still up to the operating system to be kind enough to actually have the memory ready for you. Even more, let’s assume that your operating system is kind enough to have memory enough for you to use, that still does not prevent from hardware failures. Back in 2005 I was working for a consultant firm in Belgium and my mission was to bring up a board delivered by a customer. The board was basically a PowerPC e series with some extra hardware implemented into an FPGA. As a conscious firmware engineer the first thing I did was to make sure the memory worked by writing and reading memory from it. Everything ok so far, there were no problems. So I just moved into porting redboot into the board and that is when the fun began. For those of you not very familiar with bringing up boards and bootloaders, usually the bootloader is stored into a secondary memory, usually flash or eeprom (or some other variety of ROM memory) and the processor is hooked to boot from that memory. The first thing you do in a bootloader is to initialize the mappings inside the processor and move the code you want to execute to RAM memory (not necessary but it improves speed considerably) and then you jump to that code and start doing your stuff (by the way, when doing that having a NULL pointer that equals to 0 is very useless since 0 it is a pretty perfectly valid address and many processors assume that when using linear memory you will start the memory from 0!). To my surprise the board didn’t want to boot and the processor always reported an exception. Note of the Editor: when booting it is usual to have all exception processing turned off until you have the environment up and running, since what you are doing is pretty simple this is a perfectly valid assumption. Many hours later, some low level hardware debuggers and some oscilloscope I realized that the problem was simple. The execution flag of the memory was permanently wired to 0, so there was no chance for me to use the memory for running code…. Hopefully the customer reacted quickly and we received a new FPGA model that had that fixed so we were able to continue.
With all that being said, just remember that “there are no silver bullets”. A NULL pointer is not something that can be handled only on the language side, nor even in the operating system side. So don’t trust that because you are using the language X with extensions Y and you are programming using paradigm Z you are free from being visited by the friendly NULL pointer.

Mr “*”: I think you are the only one in the whole thread that interpreted my message as “let the application crash all the time”. If that is the case, then let me assure you that my message is far from that. My message is simple, there are times where handling the a NULL pointer it is a good thing and situations where the handling will create very obscure bugs that will make debugging almost impossible. In those situations, letting the application crash is the only sensible thing to do. If you like to go the other way, i.e. handle the situation and find an alternative route then “vær så god og lykke til”.
Now regarding the abused concept of “NULL” pointer. Let’s examine the issue in detail, what is exactly a NULL pointer? it is a pointer that is pointing to a special section of memory that will trigger an exception when the memory management system tries to resolve it. It is important to notice that a NULL pointer is just a definition and it has no difference with any other pointer, except that the virtual memory address to which is pointed it is marked as a special one and it will trigger a exception when accessed. There is nothing more than that in the case of a NULL pointer.
Let’s talk about the other common problems encountered when dealing with pointers. The first one of course is that your pointer was pointing to a piece of memory that is not valid anymore. For instance you requested memory, and then released the memory. If you keep a pointer to that piece of memory, there is no warranty that what you will get after the releasing of the memory is going to be valid… there is not even a warranty that the memory is going to belong to your program at that point! Now, operating systems are quite smart beasts and for the most parts they don’t like revolving memory all the time, so you might get lucky and that page can still be a part of your memory space. Since memory is nothing but a collection of bytes (or bits if you prefer to talk in bits), whenever you reference that memory there is no way to distinguish valid data from garbage. As long as you can access the memory then the contents can be assumed to be valid. And that is the first cause of troubles, because data is going to be read and is going to be interpreted to match whatever data type you are trying to access. So, actually dereferencing a pointer and reading data from it, it is a big faith act. You trust the whole system that what you are reading is actually what you wanted to read! Situation gets a little bit better if you are doing something fancier, such as using function pointers and trying to read code from memory. Code gets interpreted by the processor and the chance that garbage is going to be valid code are minimal, however it can still happen. Although this is rare and most of the problems are caused by data, not by wrong code being executed.
What is the second problem? Well, you forgot to initialize a pointer and that pointer is pointing to the twilight zone. If for any reason that pointer points to memory inside your memory space, then you go back to case number 1. If not you simply get an invalid memory access and you crash.
But these two situations are not caused by NULL pointers. This are caused by dangling pointers, the evil brother (as somebody mentioned) of the NULL pointer.
What can one do against dangling pointers? Well…. very little, unless they point to memory that is outside your memory space, the process will continue to run and data is going to be interpreted. Some languages have tried to detect dangling pointers and some of them have been quite successful. I should say that to handle dangling pointers, just the pure semantics of a language are not enough. A whole runtime needs to be created to provide the infrastructure to isolate your program from the rest of the system. Since the memory is not controlled by you, you can count on it to be handled correctly, as long as you follow the semantic and ideas of the language you should be safe. Even languages with full memory management will require you to do things in a certain defined way in order for the runtime to know what can be freed, what can be kept and when to request more memory from the OS.
Take any language with full memory management and you will see that you are expected to do things in a very defined way. There are languages that try to mix both the benefits of memory management with the freedom of not having memory management. For instance Objective C but the mixture of both requires to be even more disciplined than when using only one scheme.
Now, let’s go back for a while to NULL pointers before getting to the final part of my argumentation. Given that a dangling pointer is something that is pointing to an area of memory that might be invalid, and that a NULL pointer is a definition, how do I can end up with a NULL pointer? Ending up with a dangling pointer can be easier than ending up with a NULL pointer, but that is language/runtime dependent. A NULL pointer is only gotten through variable assignment or via a failed memory assignment. The first case is easy to see, since all that is required is a simple:

int *p = NULL

and voila! p is a NULL pointer (adapt to the syntax of your preferred language and add salt and pepper to taste). What about the second case? Well, a well behaved memory “management” method will return NULL when it fails. Take for instance malloc(…). If the allocation fails it returns you a nicely dressed NULL pointer. It even sets the ERRNO environment variable for you so you can see what went wrong. There could be other obscures ways of getting a NULL pointer, however and since it is friday after 18:00 they escape to my imagination now.
What can you do with a NULL pointer? Well, as said, they are very easy to spot since their value is a constant and you just need to compare your pointer to that constant. The second part of the question is more difficult, since what to do when a NULL pointer is spotted is not easy to decide and I do not feel inclined to give general recommendations. However I can say that sometimes when you detect a NULL pointer the best thing to do is to take corrective actions and handle the situation, and some other situations where there is nothing you can do and the best course of action is let the app crash.
So, let’s go back to languages/runtimes and see what can be done to handle these situations. Let’s assume that we have the perfect language where whenever memory is requested, the runtime will do magic and will get you memory. Let’s assume that the concept of pointer in that language avoids the possibility of dereferencing and all you can do is to either set them to some value or read values from them. Such a thing seems quite reasonable, after all what we really want is just to store data and read data some time afterwards. Since we cannot get the “address” of a particular memory, i.e. we cannot dereference the pointer, then the chances that you are going to get a dangling pointer are slim, although it could happen. It is still to be decided how you will handle assignments between objects. Are you going to create a new object and copy the data from a to b, or are you going to try to optimize and only copy data if it is strictly required? You could just reference data from a in b and only change it in b when you actually set the value in b to a new value. I’m not going to argue about the goodness of both approaches, both are valid approaches and the decision must be taken depending on the situation at hand. If one could build such a language, then it seems all the problems with dangling pointers will be solved once and for all.
However there is still one thing that needs to be resolved, and that is the assumption of having a runtime that no matter what will give you memory when you request it. This is the equivalent of having an infinite pool of memory, which can be simulated. I used to work in projects where you could not use more than X memory, so by having nX with n>1 you were actually providing infinite memory. If that can be provided, I would definitively go that road. Unfortunately for most of us, those situations are very few and very far in between. The usual situation is the situation where you can only estimate how much memory you are going to use and how memory will be installed in the system. If at some point we request more memory than what the system can provide, voila! we will get a NULL pointer. Even if the language shields us from that, the runtime will have to provide a way for us to get the memory, so the runtime will have to come up with some memory for us to use. Any ideas?
Now, continue our assumption that the language does not let us dereference pointers, which seems to be the cause of a lot troubles when dealing with dangling pointers. So we don’t get access to the memory addresses, what could possibly go wrong? Unfortunately, the language can provide everything it can or it can be designed with all the security measures available (I can only imagine how much time a data read will take in such a system, but again if it is required and that is the only way I would use it), but the language and the runtime are still running in real hardware. And real hardware fails, and sometimes the failures are very hard to detect. For instance a bad wired connection in a board, or a memory bank that is not keeping the data for long enough. Damn, it can be even easier than that, it can be that the refresh periods for the memory were wrongly calculated so the memory is changing one or two bits randomly from time to time. It is just a matter of time until the perfectly designed language/runtime begins to fail in weird ways. So even in that particular situation you can still get a pointer that is pointing to the dark side of the moon, and with a language that has all the security measures you might even detect that, what can you do about it? Since the system cannot be trusted, the only sensible thing to do is to shut it down to avoid any major complications.
So, in summary: Even the most perfectly design system can have failures because reality is not perfect. In the real world, applications crash and sometimes that is the best we can do. Sometimes we can make sure they do not crash and we can handle the situation in a nice way, if that is possible I would strongly advice that route.
Sorry if the post was too long, but I started writing and I realized that there was no way to describe this in less words.

Software engineers need to evolve, grow some legs and stand upright and walk into the brave new world of solving real problems.

Channel your obivous brain power into something worthwhile and leave NULL behind.

I agree with ‘me’s post. Stop doing puzzles and solve worthwhile problems.

Aha, no way that NULL pointer is not welcome !
Its a best thing that can happen while debugging a code. It is an indicator that code is not working properly and such indicators are always welcome