A null-pointer dereference is a bug in which a program follows a pointer or reference that does not point at any valid object, the null value, and tries to read or write the memory it supposedly addresses. In a language like C, where null is typically address zero and that address is not mapped, the result is a crash. In higher-level languages the same mistake surfaces as a null reference exception, a NullPointerException, or a segmentation fault. Either way, an operation that assumed a value was present discovers, at the worst moment, that it was absent.
The hazard is rooted in how null is treated by the language. The ISO C standard committee draft N1570 specifies that a null pointer is guaranteed to compare unequal to a pointer to any object or function, and that dereferencing it is not a defined operation; in C terms the behavior is undefined. That undefinedness is what makes the bug both a reliability problem, since the program may crash, and a security problem, since on some systems a controllable null dereference can be turned into an exploitable fault.
The deeper criticism is that null erases a crucial distinction at the type level. A variable of type “string” might hold a string or might hold null, and the type alone does not say which. The programmer is therefore obligated to remember, at every use, that any reference might secretly be empty, and a single forgotten check produces a dereference. Tony Hoare, who introduced the null reference into ALGOL W, made exactly this point in his 2009 talk “Null References: The Billion Dollar Mistake,” recounting that he added null “simply because it was so easy to implement” and came to regard the decision as a costly error.
The modern alternative is the option type, also called Maybe or Optional. Instead of letting every reference silently be nullable, the language provides an explicit type, such as Option
Languages have adopted this idea to varying degrees. Functional languages like Haskell and ML used option types from the start; Rust and Swift build them into the core of the language and have no null reference for ordinary values; and even languages that historically embraced null, such as Kotlin and C#, have added nullability annotations and checks to push the problem back toward compile time. The trend is unmistakable: make absence explicit in the type, and the dereference bug largely disappears.
Where null remains, defensive practice still matters. Validating inputs, checking return values that can fail, and failing loudly at the boundary rather than propagating a silent null deep into the system all reduce how often a null reaches a dereference. But the most durable fix is structural, encoding the possibility of nothing in the type so the compiler enforces the check the programmer would otherwise have to remember.