Easily handled, in translation.

The compiler understands it is a pointer, and that you are checking if it is equal to nullptr, and generates the right code.

Another smart adjustment when making a new ABI is to make true represented as -1. This matches how AVX* and SIMD instructions do things. (The RISC-V people missed this opportunity, among others.) Of course when converting to int, it gets turned into 1, but compilers have absolutely no difficulty with that.

???

Pointers, as per the standard, have an implicit conversion to bool that evaluates to true if and only if the pointer is not exactly nullptr. Code like:

  if (ptr) {
    ...
  }

is guaranteed to work the way you expect it to, regardless of how null pointers are implemented.

In C, NULL is always 0. Or, more correctly, the constant ‘0’ in a pointer context is always the NULL pointer. It’s then up to the compiler to convert the NULL pointer to the actual memory address constant used for the current architecture. From pure C code, the NULL pointer will always appear to == 0, and you should never be able to tell otherwise.

Indeed, I do make an effort to write if(ptr!=NULL) (partially because it more explicitly encapsulates the intent, much like writing ptr=NULL when "clearing" the ptr) but changing the developer expectations around this sounds like a terrible idea.