Channels ▼


Void Safety: Putting an End To the Plague of Null Dereferencing

One of the benefits of progress in programming languages is to help us sleep better. Static typing is one example. If you are using a statically typed object-oriented language you know that certain errors will never occur at run time: Once the compiler accepts a call of the following form (the fundamental operation of object-oriented programming):

x.f (args)

you have the guarantee -- almost as good as a mathematical proof -- that whatever happens to x at run time, even if x is polymorphic, the corresponding object will be equipped with an operation for f, able to accept arguments args. No more waking up in the middle of the night with visions of "Method not understood" failures. A whole class of nasty, unpredictable runtime errors goes away; so does, for sleep therapists, some of the programmer clientele.

Well, not entirely. To talk of "the corresponding object" is wishful thinking: in many cases the runtime value of x is not object but a "reference", which normally denotes an object but can also be null, or "void" (the terminology we'll use). If x is void, the call x.f (args) is a "void call" (or "null dereference"). A void call will fail, causing an exception and often a program crash.

However hard we try, testing cannot eliminate the specter of void calls. As a consequence, almost every program runs the risk of hitting a void call in some execution. This time bomb is not just ticking in object-oriented programs -- almost all C programs use pointer dereferencing and have the same risk.

Since testing can never be exhaustive, the only acceptable solution is to provide a static (compile-time) guarantee of "void safety", by tightening the rules on the programming language and equipping the compiler with the corresponding checks. That's what we have done with the Eiffel language, through the ISO-ECMA standard [3], and the EiffelStudio compiler. We took inspiration from earlier work by Microsoft Research on Spec#'s "nullable types" [2]. Our solution has some significant differences; in addition, we are dealing with a production language rather than a research language, and are facing a major issue of backward compatibility.

The initial design of the Eiffel "Attached type" mechanism was described in a 2005 paper [5]; making it practical, in particular making all existing libraries void-safe, turned out to require a considerable engineering effort. In this article we'll describe both the theoretical concepts and their practical implications.

As testimony to the critical nature of this issue it is interesting to note Tony Hoare's recent comment [4]:

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.

As far as we know, the solution we describe to the "one-billion dollar mistake" is the first one in a production language and environment. It was progressively introduced in releases of EiffelStudio beginning with 6.1, and is fully implemented in 6.4, released in June of 2009.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.