{{Short description|Value indicating that a referenced dataset is invalid or doesn't exist}} In computing, a '''null pointer''' (sometimes shortened to '''nullptr''' or '''null''') or '''null reference''' is a value indicating that the pointer or reference does not refer to an 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 an object. However, in general, most languages do not offer such a guarantee for uninitialized pointers. 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 behavior. Also, in languages offering such support, the correct use depends on the individual experience of each developer and linter tools. Even when used properly, null pointers are semantically incomplete, since they do not offer the possibility to express the difference between "not applicable", "not currently known", and "not yet determined" values.<ref>{{cite journal |last1= Toussaint |first1= Etienne |last2= Guagliardo |first2= Paolo |last3= Libkin |first3= Leonid |last4= Sequeda |first4= Juan |title= Troubles with Nulls, Views from the Users |journal= Proceedings of the VLDB Endowment |date= 2022 |volume= 15 |pages= 2613–2625 |doi= 10.14778/3551793.3551818|hdl= 20.500.11820/29fe40ac-24be-4b44-a67f-5c191e97092a |hdl-access= free }}</ref>
In systems 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.
Because a null pointer does not point to a meaningful object, an attempt to access the data stored at that (invalid) memory location may cause a run-time error or immediate program crash. This is the '''null pointer error''', or '''null pointer exception'''. It is one of the most common types of software weaknesses,<ref>{{cite web |url=https://cwe.mitre.org/data/definitions/476.html |title=CWE-476: NULL Pointer Dereference |website=MITRE}}</ref> and Tony Hoare, who introduced the concept, has referred to it as a "billion dollar mistake".<ref name=":0" />
==C== In C, two null pointers of any type are guaranteed to compare equal.<ref>ISO/IEC 9899, clause 6.3.2.3, paragraph 4.</ref> The preprocessor macro <code>NULL</code> is provided, defined as an implementation-defined null pointer constant in <code><stdlib.h></code>,<ref>ISO/IEC 9899, clause 7.17, paragraph 3: ''NULL... which expands to an implementation-defined null pointer constant...''</ref> which in C99 can be portably expressed with {{code|#define NULL ((void*)0)|c}}, the integer value <code>0</code> converted to the type <code>void*</code> (see pointer to void type).<ref>ISO/IEC 9899, clause 6.3.2.3, paragraph 3.</ref> Since C23, a null pointer is represented with <code>nullptr</code> which is of type <code>nullptr_t</code> (first introduced to C++11), providing a type safe null pointer.<ref name="N3042">{{cite web |title=WR14-N3042: Introduce the nullptr constant |url=https://open-std.org/JTC1/SC22/WG14/www/docs/n3042.htm |website=open-std.org |archive-url=https://web.archive.org/web/20221224043228/https://open-std.org/JTC1/SC22/WG14/www/docs/n3042.htm |archive-date=December 24, 2022 |date=2022-07-22 |url-status=live}}</ref>
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,<ref name="ub"/> 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 <code>0000:0000</code> 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; if a null pointer is represented as a pointer to that address, dereferencing it will lead to that behavior. There are occasions when dereferencing a 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 interrupt descriptor table (IDT) at physical address 0 of the machine by dereferencing a pointer with the same value as 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.<ref>{{Cite web |last=Lattner |first=Chris |date=2011-05-13 |title=What Every C Programmer Should Know About Undefined Behavior #1/3 |url=https://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html |url-status=live |archive-url=https://web.archive.org/web/20230614124121/https://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html |archive-date=2023-06-14 |access-date=2023-06-14 |website=blog.llvm.org |language=en}}</ref>
==C++== In C++, while the <code>NULL</code> macro was inherited from C, the integer literal for zero has been traditionally preferred to represent a null pointer constant.<ref>{{cite book |last1=Stroustrup |first1=Bjarne |authorlink1=Bjarne Stroustrup |title=The C++ Programming Language |edition=14th printing of 3rd |date=March 2001 |publisher=Addison–Wesley |location=United States and Canada |isbn=0-201-88954-4 |page=[https://archive.org/details/cprogramminglang00stro_0/page/88 88] |chapter=Chapter 5: <br />The <code>const</code> qualifier (§5.4) prevents accidental redefinition of <code>NULL</code> and ensures that <code>NULL</code> can be used where a constant is required. }}</ref> However, C++11 introduced the explicit null pointer constant <code>nullptr</code> and type <code>nullptr_t</code> to be used instead, providing a type-safe null pointer. <code>nullptr</code> and type <code>nullptr_t</code> were later introduced to C in C23.
==Other languages== Programming languages use different literals for the ''null pointer''. In Java and C#, the literal <code>null</code> is provided as a literal for reference types. In Pascal and Swift, a null pointer is called <code>nil</code>. In Eiffel, it is called a <code>void</code> reference. In Rust, the absence of a value is denoted as <code>None</code>, but a true null pointer is <code>std::ptr::null()</code>.
==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. MITRE lists the null pointer error as one of the most commonly exploited software weaknesses.<ref>{{cite web |url=https://cwe.mitre.org/data/definitions/476.html |title=CWE-476: NULL Pointer Dereference |website=MITRE}}</ref>
* In C, dereferencing a null pointer is undefined behavior.<ref name="ub">ISO/IEC 9899, clause 6.5.3.2, paragraph 4, esp. footnote 87.</ref> Many implementations cause such code to result in the program being halted with an access violation, because the null pointer representation is chosen to be an address that is never allocated by the system for storing objects. However, this behavior is not universal. It is also not guaranteed, since compilers are permitted to optimize programs under the assumption that they are free of undefined behavior. This behaviour is the same in C++, as there is no null pointer exception in the C++ language. On platforms such as Unix-like systems and Windows with the Visual Studio compiler, an access violation causes a C/C++ <code>SIGSEGV</code> signal to be issued. Although in C/C++ null dereferences are not exceptions which can be caught in C++ <code>try</code>/<code>catch</code> blocks, it is possible to "catch" such an access violation by using (<code>std::</code>)<code>signal()</code> in C/C++ to specify a handler to be called when that signal is issued. ** Some external C++ libraries, such as POCO C++ Libraries, include a <code>NullPointerException</code> class. Unlike Java, where <code>java.lang.NullPointerException</code> extends <code>java.lang.RuntimeException</code>, <code>Poco::NullPointerException</code> instead extends <code>Poco::LogicException</code>.<ref>{{cite web|title=Class Poco::NullPointerException|url=https://docs.pocoproject.org/current/Poco.NullPointerException.html|access-date=17 August 2025|publisher=docs.pocoproject.org}}</ref> * In Cyclone, a failed null pointer check will throw a <code>Null_Exception</code>. * In D, much like C++, a null pointer dereference results in a segmentation fault. * In Delphi and many other Pascal implementations, the constant {{code|nil}} represents a null pointer to the first address in memory, which is also used to initialize managed variables. Dereferencing it raises an external OS exception which is mapped onto a Pascal {{code|EAccessViolation}} exception instance if the {{code|System.SysUtils}} unit is linked in the {{code|uses}} clause. * In Java, access to a null reference (<code>null</code>) causes a {{Javadoc:SE|java/lang|NullPointerException}} (NPE), which can be caught by error handling code, but the preferred practice is to ensure that such exceptions never occur. * In .NET and C#, access to null reference (<code>null</code>) causes a {{code|System.NullReferenceException}} to be thrown. Although catching these is generally considered bad practice, this exception type can be caught and handled by the program. * In Objective-C, messages may be sent to a {{code|nil}} object (which is a null pointer) without causing the program to be interrupted; the message is simply ignored, and the return value (if any) is {{code|nil}} or {{code|0}}, depending on the type.<ref>{{cite web |title=The Objective-C 2.0 Programming Language |url=https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocObjectsClasses.html#//apple_ref/doc/uid/TP30001163-CH11-SW7 |at=section "Sending Messages to nil"}}</ref> * In Rust, dereferencing a null pointer (<code>std::ptr::null()</code>) in an <code>unsafe</code> block results in undefined behaviour, which usually results in a segmentation fault or corrupted memory. * Before the introduction of Supervisor Mode Access Prevention (SMAP), a null pointer dereference bug could be exploited by mapping page zero into the attacker's address space and hence causing the null pointer to point to that region. This could lead to code execution in some cases.<ref>{{cite web |url=https://project-zero.issues.chromium.org/issues/42452311 |title=OS X exploitable kernel NULL pointer dereference in AppleGraphicsDeviceControl}}</ref>
==Mitigation== While there could be languages with no nulls, most do have the possibility of nulls so there are techniques to avoid or aid debugging null pointer dereferences.<ref name="BondNethercote2007">{{cite book|last1=Bond|first1=Michael D.|last2=Nethercote|first2=Nicholas|last3=Kent|first3=Stephen W.|last4=Guyer|first4=Samuel Z.|last5=McKinley|first5=Kathryn S.|title=Proceedings of the 22nd annual ACM SIGPLAN conference on Object oriented programming systems and applications - OOPSLA '07|chapter=Tracking bad apples|year=2007|pages=405|doi=10.1145/1297027.1297057|isbn=9781595937865|s2cid=2832749}}</ref> Bond et al. suggest modifying the Java virtual machine (JVM) to keep track of null propagation.<ref name="BondNethercote2007"/>
There are three levels of handling null references, in order of effectiveness:
# languages with no null; # languages that can statically analyse code to avoid the possibility of null dereference at run time; # if null dereference can occur at runtime, tools that aid debugging.
Pure functional languages are an example of level 1 since no direct access is provided to pointers and all code and data is immutable. User code running in interpreted or virtual-machine languages generally does not suffer the problem of null pointer dereferencing.{{dubious|VM claim|date=September 2024}}
Where a language does provide or utilise pointers which could become void, it is possible to avoid runtime null dereferences by providing compilation-time checking via static analysis or other techniques, with syntactic assistance from language features such as those seen in the Eiffel programming language with Void safety<ref>{{cite web | url=https://www.eiffel.org/doc/eiffel/Void-safety-_Background%2C_definition%2C_and_tools |title=Void-safety: Background, definition, and tools|access-date=2021-11-24 }}</ref> to avoid null dereferences, D,<ref name="SafeD">{{cite web |title=SafeD – D Programming Language |url=http://dlang.org/safed.html |author=Bartosz Milewski |access-date=17 July 2014}}</ref> and Rust.<ref>{{cite web|title=Fearless Security: Memory Safety|url=https://hacks.mozilla.org/2019/01/fearless-security-memory-safety/|access-date=4 November 2020|archive-date=8 November 2020|archive-url=https://web.archive.org/web/20201108003116/https://hacks.mozilla.org/2019/01/fearless-security-memory-safety/|url-status=live}}</ref> Nullable type systems have also been widely adopted in mainstream programming languages: Kotlin, Swift, and TypeScript include them from the start, while C# and Scala have been retrofitted with nullable type systems.<ref>{{cite journal |last1= Madsen |first1= Magnus |last2= Pol |first2= Jaco van de |title= Relational nullable types with Boolean unification |journal= Proceedings of the ACM on Programming Languages |date= 2021 |volume= 5 |pages= 1–28 |doi= 10.1145/3485487}}</ref>
In some languages, analysis can be performed using external tools, but these are weak compared to direct language support with compiler checks since they are limited by the language definition itself.
The last resort of level 3 is when a null reference occurs at runtime; debugging aids can help.
==History== In 2009, Tony Hoare stated<ref name=":0">{{cite web |url=http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare |title=Null References: The Billion Dollar Mistake |publisher=InfoQ.com |date=2009-08-25 |author=Tony Hoare |author-link=Tony Hoare }}</ref><ref>{{cite web |url=https://qconlondon.com/london-2009/qconlondon.com/london-2009/presentation/Null%2BReferences_%2BThe%2BBillion%2BDollar%2BMistake.html |title=Presentation: "Null References: The Billion Dollar Mistake" |publisher=InfoQ.com |date=2009-08-25 |author=Tony Hoare |author-link=Tony Hoare }}</ref> <ref>{{Cite web |last=Contieri |first=Maxi |date=2025-06-18 |title=Code Smell 304 - Null Pointer Exception |url=https://maximilianocontieri.com/code-smell-304-null-pointer-exception |access-date=2025-06-18 |website=Maximiliano Contieri - Software Design |language=en}}</ref> 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":
{{quote|I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.}}
==See also== * Memory debugger * Zero page
==Notes== {{refs}}
==References== {{refbegin}} * {{cite book |ref = c-std |author = Joint Technical Committee ISO/IEC JTC 1, Subcommittee SC 22, Working Group WG 14 |title = International Standard ISO/IEC 9899 |date = 2007-09-08<!-- 19:22:32 +0000 -->|url = http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf |type = Committee Draft }} {{refend}}
{{Nulls}} {{Hoare}}
Category:Pointers (computer programming)