Because NULL is dogshit. It's a #define 0. That's not one way to do an operation, that's one way to do an operation, horribly badly. That int on your stack ? Sure it can equal NULL. Hope that wasn't the result of (2 - 2).

In C the NULL macro can be defined as either (void*)0 or 0. It's only mandated as 0 in C++.

The nullptr concept was introduced into C to fix a type ambiguity when NULL is used with generic selection or varargs functions. The ambiguity could have been solved by mandating that NULL be defined as (void*)0. My issue with nullptr is its an overkill solution that unnecessarily duplicates the concept of NULL in the language.

I agree, it should have been (void*)0. I doubt that nullptr_t will see much use (as much as _Generic is a fringe addition), but we'll find out.

Well, since 0 is guaranteed to compare equal to the null pointer, my current code compare my pointers to it directly:

  if (ptr != 0) { foo(*ptr); }

The type mismatch is ugly, but that saves me an include (this particular code minimises its dependencies to maximise portability).