Skip to content

Null dereference

The failure where code operates on a reference under the unstated assumption that the object exists, while the reference is in fact absent — so the defect is the missing existence-precondition check, not the absence itself.

Core Idea

Null dereference is the failure in which a program operates on a reference, pointer, or handle under the static assumption that the object exists there, while the reference is in fact absent — null, uninitialized, dangling after free, or never allocated on the path taken. The result ranges from a crash to undefined behaviour to a silent garbage value propagating downstream. The structural fault is not the absence — absent objects are normal — but the missing existence precondition: a static "this object exists here" the code carries but never verifies, valid on the common path and false on uncommon ones.

Scope of Application

Null dereference lives across the reliability and defensive-programming subfields of software engineering — wherever a system has reference semantics and a discrete notion of an absent object.

  • Application code — a method invoked on a null receiver, or a pointer dereferenced after free.
  • Distributed systems — an RPC client assuming a remote service is reachable, not handling the partition.
  • Cloud operations — a deployment assuming a database, bucket, secret, or ConfigMap exists.
  • API contracts — a consumer treating a documented-optional field as required.
  • Database access — result[0] on a query expected to return at least one row.

Clarity

The label separates two things the "null pointer bug" framing runs together: the object's absence and the code's unverified assumption that it is present. The naive reading blames the absence and reaches for remedies that miss the defect. Naming null dereference relocates the fault to the silent static precondition, turning an opaque crash into a diagnostic sequence — which reference was absent, what assumption did the code carry, where did it enter — and revealing that the bug's rarity is a property of the inputs, not a sign the code is sound.

Manages Complexity

A parade of unrelated crashes across the stack collapses to a single structural fact: every one is an unchecked existence precondition. The engineer's task changes from an open-ended "where might it crash" to a bounded enumeration of dereference sites, each carrying one question: is the value's presence guaranteed, or assumed? The remedy compresses to two cases sorted by one property of the precondition — liftable into the type system, or irreducibly runtime.

Abstract Reasoning

The concept licenses a diagnostic (relocate the fault to the unverified assumption; read field-rarity as an input-distribution fact), a per-site audit question (guaranteed or assumed presence?), a boundary-drawing move sorting the remedy into a static-versus-dynamic fork (type-system optionality versus an explicit runtime branch), and an interventionist move (make the existence assumption explicit and enforce it at the operation site).

Knowledge Transfer

Within software engineering the porting is direct and as mechanism, because the per-site existence-precondition question and the static-versus-dynamic fork are implementation-agnostic across application code, distributed systems, cloud ops, API contracts, and databases — one substrate with reference semantics. Beyond software the general pattern travels as co-instances — a supply chain assuming a solvent vendor, a plan assuming a current contact list — an unchecked existence precondition whose fault lies in the assumption, not the absence. That parent (unverified_precondition / verification) carries the lesson; the typed-Option, null-check, lifetime-annotation apparatus stays home.

Relationships to Other Abstractions

Local relationship map for Null dereferenceParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Null dereferenceDOMAINDomain-specific abstraction: Pointer — presupposesPointerDOMAIN

Current abstraction Null dereference Domain-specific

Parents (1) — more general patterns this builds on

  • Null dereference presupposes Pointer Domain-specific

    Null dereference presupposes an indirect reference such as a pointer whose no-referent state is used as though it named a live object.

Hierarchy paths (3) — routes to 3 parentless roots

Neighborhood in Abstraction Space

Null dereference sits in a sparse region of the domain-specific corpus (97th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Software Dependency & Structural Decay (5 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-07-12