q2K BHP
Black History Portal
THE BHP WIRE —
HIDDEN TRUTHS
What's New!
THE JOURNEY THROUGH TIME

Explore Black History

Explore the people, places, events, achievements, struggles and stories that shaped our journey.

✊🏾

Civil Rights

Movements, leaders, victories and the continuing fight for equality.

⚙️

Black Inventors

Innovation, patents, science, technology and world-changing contributions.

🏆

Sports

Pioneers, champions, Negro Leagues, records, activism and excellence.

♟️

People

Meet the people whose lives, choices and achievements shaped the journey.

📍

Places

Black towns, communities, institutions and places where history happened.

📜

Events

Moments that changed communities, movements, institutions and the nation.

Enter a person, place, event, or topic.
MY'STORY

The MOVE Fire

This is a personal recollection on the Move fire on May 13, 1985 Philadelphia police fired thousands of rounds at the MOVE house, city officials approved dropping an explosive device on the roof, the resulting fire was allowed to burn, 11 people—including five children—died, and 61 homes were destroyed. Philadelphia City Council later called it a “brutal attack carried out by the City of Philadelphia on its own citizens” and acknowledged that no individual faced criminal consequences for the bombing. One timeline correction worth preserving for the BHP record: the major previous MOVE-police confrontation was August 8, 1978, about seven years before the bombing, not a year or two earlier. Officer James Ramp was killed, other police and firefighters were wounded, nine MOVE members were later convicted, and television cameras recorded police beating Delbert Africa during his arrest. The 1985 MOVE Commission later specifically criticized city planners for failing to adequately use lessons from that 1978 confrontation. And that actually strengthens the point you’re making: 1985 did not happen without precedent or institutional memory. There had already been a deadly confrontation with MOVE, years of conflict, negotiations and police involvement before Osage Avenue.

MORE →
BLACK FACTS
The Truths They Never Taught You...

Shirley Chisholm — Unbought and Unbossed

In 1968 Shirley Chisholm became the first Black woman elected to the United States Congress. In 1972 she launched a campaign for the Democratic presidential nomination, breaking another political barrier.

MORE →
BHP gathered finds from its connected research sources. Showing the 4 strongest Black History matches.
← BACK TO RESULTS
Wikipedia

Null pointer

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.[1]

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,[2] and Tony Hoare, who introduced the concept, has referred to it as a "billion dollar mistake".[3]

C

[edit]

In C, two null pointers of any type are guaranteed to compare equal.[4] The preprocessor macro NULL is provided, defined as an implementation-defined null pointer constant in <stdlib.h>,[5] which in C99 can be portably expressed with #define NULL ((void*)0), the integer value 0 converted to the type void* (see pointer to void type).[6] Since C23, a null pointer is represented with nullptr which is of type nullptr_t (first introduced to C++11), providing a type safe null pointer.[7]

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,[8] 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 0000:0000 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.[9]

C++

[edit]

In C++, while the NULL macro was inherited from C, the integer literal for zero has been traditionally preferred to represent a null pointer constant.[10] However, C++11 introduced the explicit null pointer constant nullptr and type nullptr_t to be used instead, providing a type-safe null pointer. nullptr and type nullptr_t were later introduced to C in C23.

Other languages

[edit]

Programming languages use different literals for the null pointer. In Java and C#, the literal null is provided as a literal for reference types. In Pascal and Swift, a null pointer is called nil. In Eiffel, it is called a void reference. In Rust, the absence of a value is denoted as None, but a true null pointer is std::ptr::null().

Null dereferencing

[edit]

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.[11]

  • In C, dereferencing a null pointer is undefined behavior.[8] 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++ SIGSEGV signal to be issued. Although in C/C++ null dereferences are not exceptions which can be caught in C++ try/catch blocks, it is possible to "catch" such an access violation by using (std::)signal() 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 NullPointerException class. Unlike Java, where java.lang.NullPointerException extends java.lang.RuntimeException, Poco::NullPointerException instead extends Poco::LogicException.[12]
  • In Cyclone, a failed null pointer check will throw a Null_Exception.
  • In D, much like C++, a null pointer dereference results in a segmentation fault.
  • In Delphi and many other Pascal implementations, the constant 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 EAccessViolation exception instance if the System.SysUtils unit is linked in the uses clause.
  • In Java, access to a null reference (null) causes a 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 (null) causes a 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 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 nil or 0, depending on the type.[13]
  • In Rust, dereferencing a null pointer (std::ptr::null()) in an unsafe 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.[14]

Mitigation

[edit]

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.[15] Bond et al. suggest modifying the Java virtual machine (JVM) to keep track of null propagation.[15]

There are three levels of handling null references, in order of effectiveness:

  1. languages with no null;
  2. languages that can statically analyse code to avoid the possibility of null dereference at run time;
  3. 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 – discuss]

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[16] to avoid null dereferences, D,[17] and Rust.[18] 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.[19]

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

[edit]

In 2009, Tony Hoare stated[3][20][21] 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":

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

[edit]

Notes

[edit]
  1. ^ Toussaint, Etienne; Guagliardo, Paolo; Libkin, Leonid; Sequeda, Juan (2022). "Troubles with Nulls, Views from the Users". Proceedings of the VLDB Endowment. 15: 2613–2625. doi:10.14778/3551793.3551818. hdl:20.500.11820/29fe40ac-24be-4b44-a67f-5c191e97092a.
  2. ^ "CWE-476: NULL Pointer Dereference". MITRE.
  3. ^ a b Tony Hoare (2009-08-25). "Null References: The Billion Dollar Mistake". InfoQ.com.
  4. ^ ISO/IEC 9899, clause 6.3.2.3, paragraph 4.
  5. ^ ISO/IEC 9899, clause 7.17, paragraph 3: NULL... which expands to an implementation-defined null pointer constant...
  6. ^ ISO/IEC 9899, clause 6.3.2.3, paragraph 3.
  7. ^ "WR14-N3042: Introduce the nullptr constant". open-std.org. 2022-07-22. Archived from the original on December 24, 2022.
  8. ^ a b ISO/IEC 9899, clause 6.5.3.2, paragraph 4, esp. footnote 87.
  9. ^ Lattner, Chris (2011-05-13). "What Every C Programmer Should Know About Undefined Behavior #1/3". blog.llvm.org. Archived from the original on 2023-06-14. Retrieved 2023-06-14.
  10. ^ Stroustrup, Bjarne (March 2001). "Chapter 5:
    The const qualifier (§5.4) prevents accidental redefinition of NULL and ensures that NULL can be used where a constant is required.". The C++ Programming Language (14th printing of 3rd ed.). United States and Canada: Addison–Wesley. p. 88. ISBN 0-201-88954-4.
  11. ^ "CWE-476: NULL Pointer Dereference". MITRE.
  12. ^ "Class Poco::NullPointerException". docs.pocoproject.org. Retrieved 17 August 2025.
  13. ^ "The Objective-C 2.0 Programming Language". section "Sending Messages to nil".
  14. ^ "OS X exploitable kernel NULL pointer dereference in AppleGraphicsDeviceControl".
  15. ^ a b Bond, Michael D.; Nethercote, Nicholas; Kent, Stephen W.; Guyer, Samuel Z.; McKinley, Kathryn S. (2007). "Tracking bad apples". Proceedings of the 22nd annual ACM SIGPLAN conference on Object oriented programming systems and applications - OOPSLA '07. p. 405. doi:10.1145/1297027.1297057. ISBN 9781595937865. S2CID 2832749.
  16. ^ "Void-safety: Background, definition, and tools". Retrieved 2021-11-24.
  17. ^ Bartosz Milewski. "SafeD – D Programming Language". Retrieved 17 July 2014.
  18. ^ "Fearless Security: Memory Safety". Archived from the original on 8 November 2020. Retrieved 4 November 2020.
  19. ^ Madsen, Magnus; Pol, Jaco van de (2021). "Relational nullable types with Boolean unification". Proceedings of the ACM on Programming Languages. 5: 1–28. doi:10.1145/3485487.
  20. ^ Tony Hoare (2009-08-25). "Presentation: "Null References: The Billion Dollar Mistake"". InfoQ.com.
  21. ^ Contieri, Maxi (2025-06-18). "Code Smell 304 - Null Pointer Exception". Maximiliano Contieri - Software Design. Retrieved 2025-06-18.

References

[edit]
  • Joint Technical Committee ISO/IEC JTC 1, Subcommittee SC 22, Working Group WG 14 (2007-09-08). International Standard ISO/IEC 9899 (PDF) (Committee Draft).{{cite book}}: CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link)

Source: Wikipedia. Article content is retrieved live through the MediaWiki API.

No preview image
Wikipedia

Null pointer

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. 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, and Tony Hoare, who introduced the concept, has referred to it as a "billion dollar mistake".

MORE →
No preview image
Wikipedia

Tombstone (programming)

Tombstones are a mechanism to detect dangling pointers and mitigate the problems they can cause in computer programs. Dangling pointers can appear in certain computer programming languages, e.g. C, C++ and assembly languages. A tombstone is a structure that acts as an intermediary between a pointer and its target, often heap-dynamic data in memory. The pointer – sometimes called the handle – points only at tombstones and never to its actual target. When the data is deallocated, the tombstone is set to a null (or, more generally, to a value that is illegal for a pointer in the given runtime environment), indicating that the variable no longer exists. This mechanism prevents the use of invalid pointers, which would otherwise access the memory area that once belonged to the now deallocated variable, although it may already contain other data, in turn leading to corruption of in-memory data. Depending on the operating system, the CPU can automatically detect such an invalid access (e.g. for the null value: a null pointer dereference error). This supports in analyzing the actual reason, a programming error, in debugging, and it can also be used to abort the program in production use, to prevent it from continuing with invalid data structures. In more generalized terms, a tombstone can be understood as a marker for "this data is no longer here". For example, in filesystems it may be efficient when deleting files to mark them as "dead" instead of immediately reclaiming all their data blocks. The downsides of using tombstones include a computational overhead and additional memory consumption: extra processing is necessary to follow the path from the pointer to data through the tombstone, and extra memory is necessary to retain tombstones for every pointer throughout the program. One other problem is that all the code that needs to work with the pointers in question needs to be implemented to use the tombstone mechanism. Among popular programming languages, C++ implements the tombstone pattern in its standard library as a weak pointer using std::weak_ptr. Built–in support by programming languages or the compiler is not necessary to use this mechanism.

MORE →
No preview image
Wikipedia

Sentinel value

In computer programming, a sentinel value (also referred to as a flag value, trip value, rogue value, signal value, or dummy data) is a special value in the context of an algorithm which uses its presence as a condition of termination, typically in a loop or recursive algorithm. The sentinel value is a form of in-band data that makes it possible to detect the end of the data when no out-of-band data (such as an explicit size indication) is provided. The value should be selected in such a way that it is guaranteed to be distinct from all legal data values since otherwise, the presence of such values would prematurely signal the end of the data (the semipredicate problem). A sentinel value is sometimes known as an "Elephant in Cairo", due to a joke where this is used as a physical sentinel. In safe languages, most sentinel values could be replaced with option types, which enforce explicit handling of the exceptional case. Sometimes, it may make more sense to return a null pointer or null value, or when working with option types, return the none/null option.

MORE →
No preview image
Wikipedia

Pyramid of doom (programming)

In computer programming, the Pyramid of Doom is a term that refers to code that becomes deeply nested with if statements, loops, or other control structures, thereby reducing readability, testability, and maintainability. It is so called because the code then begins to resemble a pyramid in its shape. A common challenge facing systems programmers is that before an operation can be performed, a number of conditions must first be checked to confirm that the operation can be successfully performed. For example, before data can be written to a file, it must be confirmed that 1) the program has the file open for writing; 2) the program has the necessary permissions to write the data; 3) the data to be written is available; 4) the data to be written is of a valid size. A failure at any of these steps means that the write operation cannot be completed and an error should be returned to the calling program. There are several ways that these multiple required tests can be written in the source code. One way is to check each condition in turn and if a condition fails, return from the subroutine at that point, indicating an error condition exists. This style of coding has the disadvantage that the subroutine returns from multiple (possibly many) points and some coding standards discourage having multiple return points. Another way to is to check each condition and if the condition succeeds, enter a deeper block of code that checks the next condition and so on. The deepest enclosing block of code is only reached if all of the precondition tests are successful. This style of coding has the disadvantage that the indentation level increases with every test performed. If many tests are required, the enclosed blocks of code can march off the page to the right margin. This typographical effect is referred to as the pyramid of doom. For example, the pyramid of doom is commonly seen when checking for null pointers or handling callbacks. Two examples of the term are related to a particular programming style in early versions of JavaScript, and the nesting of if statements that occurs in object-oriented programming languages when one of the objects may be a null pointer.

MORE →
TOPIC OF THE DAY

Greenwood / Black Wall Street

Before the 1921 destruction of Tulsa’s Greenwood District, Black residents had created a remarkable center of business and community life. The district included stores, professional offices, entertainment venues and homes owned by Black citizens. Understanding Greenwood means learning what was built—not only what was burned.

MORE →
TRIVIA QUESTION OF THE DAY

Which heavyweight champion was known as the “Brown Bomber”?

Joe Louis.