Editing Null pointer (section)

== C ==

In [[C (programming language)|C]], two null pointers of any type are guaranteed to compare equal.<ref>[[#c-std|ISO/IEC 9899]], clause 6.3.2.3, paragraph 4.</ref> Prior to C23, the preprocessor macro <code>NULL</code> was provided, defined as an implementation-defined null pointer constant in <code><[[stdlib.h]]></code>,<ref>[[#c-std|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 as <code>((void *)0)</code>, the integer value <code>0</code> [[Type conversion|converted]] to the type <code>void*</code> (see [[pointer to void type]]).<ref>[[#c-std|ISO/IEC 9899]], clause 6.3.2.3, paragraph 3.</ref> Since [[C23 (C standard revision)|C23]], a null pointer is represented with <code>nullptr</code> which is of type <code>nullptr_t</code> (originally 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]]&nbsp;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 [[computer memory|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 handling|exception]] that can be caught by program code. There are, however, certain circumstances where this is not the case. For example, in [[Intel x86|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&nbsp;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>