Null pointer
In computing, a null pointer or null reference is a value saved for indicating that the pointer or reference does not refer to a valid object. Programs routinely use null pointers to represent conditions such as the end of a list of unknown length or the failure to perform some action; this use of null pointers can be compared to nullable types and to the "Nothing" value in an option type. A null pointer should not be confused with an uninitialized pointer: a null pointer is guaranteed to compare unequal to any pointer that points to a valid  object. However, depending on the language and implementation, an uninitialized pointer may not have any such guarantee. It might compare equal to other, valid pointers; or it might compare equal to null pointers. It might do both at different times; or the comparison might be undefined behaviour. C. In C, two null pointers of any type are guaranteed to compare equal. The preprocessor macro codice_1 is defined as an implementation-defined null pointer constant, which in C99 can be portably expressed as codice_2 which means that the integer value codice_3 converted to the type codice_4 (pointer to void). The C  standard does not say that the null pointer is the same as the pointer to memory address 0, though that may be the case in practice. Dereferencing a null pointer is undefined behavior in C, and a conforming implementation is allowed to assume that any pointer that is dereferenced is not null. In practice, dereferencing a null pointer may result in an attempted read or write from memory that is not mapped, triggering a segmentation fault or memory access violation. This may manifest itself as a program crash, or be transformed into a software exception that can be caught by  program code. There are, however, certain circumstances where this is not the case. For example, in x86 real mode, the address codice_5 is readable and also usually writable, and dereferencing a pointer to that address is a perfectly valid but typically unwanted action that may lead to undefined but non-crashing behavior in the application. There are occasions when dereferencing the pointer to address zero "is" intentional and well-defined; for example, BIOS code written in C for 16-bit real-mode x86 devices may write the IDT at physical address 0 of the machine by dereferencing a null pointer  for writing. It is also possible for the compiler to optimize away the null pointer dereference, avoiding a segmentation fault but causing other undesired behavior. C++. In C++, while the codice_1 macro was inherited from C, the integer literal for zero has been traditionally preferred to represent a null pointer constant. However, C++11 has introduced the explicit null pointer constant codice_7 to be used instead. Other languages. In some programming language environments (at least one proprietary Lisp implementation, for example), the value used as the null pointer (called codice_8 in Lisp) may actually be a pointer to a block of  internal data useful to the implementation (but not explicitly reachable from user programs), thus allowing the same register to be used as a useful constant and a quick way of accessing implementation internals. This is known as the "codice_8 vector". In languages with a tagged architecture, a possibly null pointer can be replaced with a tagged union which enforces explicit handling of the exceptional case; in fact, a possibly null pointer can be seen as a tagged pointer with a computed tag. Programming languages use different literals for the "null pointer". In Python, for example, a null value is called  codice_10. In Pascal and Swift, a null pointer is called codice_8. In Eiffel, it is called a codice_12 reference. Null dereferencing. Because a null pointer does not point to a meaningful object, an attempt to dereference (i.e., access the data stored at that memory location) a null pointer usually (but not always) causes a run-time error or immediate program crash. Mitigation. There are techniques to facilitate debugging null pointer dereferences. Bond et al. suggest to modify the JVM in order to keep track of null propagation. The idea of the Casper system is to use source code transformation in  order to track this propagation, without modifying the JVM. In some cases, it is possible to automatically generate a patch to fix null pointer exceptions. Pure functional languages, and user code run in many interpreted or virtual-machine languages do not suffer the problem of null pointer dereferencing, since no direct access is provided to pointers and, in the case of pure functional languages, all code and data is immutable. Where a language does provide or utilise pointers which could otherwise become void, it may be possible to mitigate or avoid runtime null dereferences by providing compilation-time checking via  static analysis or other techniques, with a burgeoning movement toward syntactic assistance from language features such as those seen in modern versions of the Eiffel programming language, D, and Rust. Similar analysis can be performed using external tools, in some languages. History. In 2009, Sir Tony Hoare stated that he invented the null reference in 1965 as part of the ALGOL W language. In that 2009 reference Hoare describes his invention as a "billion-dollar mistake":