nullptr in C23

Introduction

Since its creation in the 1970s, C has used the preprocessor to define a macro for the “null pointer.” Originally, it was defined as:

#define NULL  0

or perhaps 0L since void and the ability to use void* weren’t added until C89. This required C to have a special case for the integer literals 0 and 0L (and 0LL once long long was added in C99, as well as their unsigned variants) allowing only them to be converted to any pointer type implicitly:

char *p = 0;  // OK

char *q = 1;  // error

For simplicity, going forward, whenever I mention 0 as a possible definition of NULL, interpret that to mean either 0 or any one of 0U, 0L, 0UL, 0LL, or 0ULL.

Since C89, NULL is typically instead defined as:

#define NULL  ((void*)0)

which is better; however, some platforms still define it simply as 0. This lack of consistency can sometimes cause portability problems, i.e., code that relies upon NULL defined one way breaks on platforms where it’s defined a different way.

Problems

One case where how NULL is defined can matter is with functions having variadic arguments:

printf( "%p\n", NULL );  // may be undefined behavior

If NULL is defined as 0 and sizeof(int) < sizeof(void*), then half the value of the argument might be garbage, but definitely undefined behavior.

While you’d most likely never call printf with NULL like that, you could have your own variadic function that expects a NULL-terminated list of pointers and have the same problem.

Another case is if you use _Generic:

#define F(X)          \

  _Generic( (X),      \

    int  : f_int,     \

    void*: f_void_ptr \

  )( (X) )

For F(NULL), which function gets called depends on how NULL is defined.

nullptr

To fix these problems, C23 borrowed the nullptr keyword from C++ that’s a literal for the null pointer. Like void* and 0, nullptr implicitly converts to any type of pointer; unlike NULL, it’s guaranteed to be a pointer.

Why not just fix NULL, i.e., always define it to be ((void*)0)? The proposal mentions it, but doesn’t elaborate. My guess is that if your code continues to use NULL, you may or may not get the “fixed” version depending on the platform, so you’re no better off. You could test for NULL at configure-time, but it’s not clear what you’d do if it’s not the NULL you want; plus testing for things at configure-time is more of a pain. If you use nullptr, you’re obviously getting what you want. It also increases interoperability with C++.

The use of nullptr fixes cases when used with variadic arguments, but what about _Generic? To fix that, nullptr also needs to have a distinct type. Curiously, the stddef.h header now includes:

#define nullptr_t  typeof(nullptr)

that is, it defines nullptr_t using typeof to be whatever distinct type the compiler uses internally for nullptr. It may seem a bit weird not to define nullptr_t as a keyword also, but it works. Given that, you can now use it in _Generic:

#define F(X)               \

  _Generic( (X),           \

    int      : f_int       \

    void*    : f_void_ptr, \

    nullptr_t: f_null_ptr  \

  )( (X) )

The only time f_null_ptr would get called is if you passed nullptr.

Well, that’s not entirely true. You could also declare a variable of type nullptr_t and pass that. But the only value such a variable can ever legally have is nullptr, so I can’t think of a legitimate reason for ever declaring and using such a variable.

Conclusion

The addition of nullptr eliminates an old wart in C fixing a few portability problems and increases interoperability with C++. If your compiler supports it, you should use nullptr in new C code.