Editing Null pointer (section)

== 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 (programming language)|C]], dereferencing a null pointer is [[undefined behavior]].<ref name="ub">[[#c-std|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.
* In [[D (programming language)|D]], much like C++, a null pointer dereference results in a segmentation fault.
* In [[Delphi (programming language)|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 (programming language)|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 [[Lisp_(programming_language)|Lisp]], {{code|nil}} is a [[first class object]]. By convention, <code>(first nil)</code> is {{code|nil}}, as is <code>(rest nil)</code>. So dereferencing {{code|nil}} in these contexts will not cause an error, but poorly written code can get into an infinite loop.
* In [[.Net (programming language)|.NET]] and [[C Sharp (programming language)|C#]], access to null reference (<code>null</code>) causes a {{code|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>''The Objective-C 2.0 Programming Language'', [https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocObjectsClasses.html#//apple_ref/doc/uid/TP30001163-CH11-SW7 section "Sending Messages to nil"].</ref>
* In [[Python (programming language)|Python]], dereferencing <code>None</code> raises an <code>AttributeError</code>, as <code>NoneType</code> has no (user-facing) methods or attributes defined.
* In [[Rust (programming language)|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 [[Zero page|page zero]] into the attacker's [[address space]] and hence causing the null pointer to point to that region. This could lead to [[Arbitrary code execution|code execution]] in some cases.<ref>[https://project-zero.issues.chromium.org/issues/42452311 "OS X exploitable kernel NULL pointer dereference in AppleGraphicsDeviceControl"]</ref>