Redefining NULL

Solution 1:

The C standard does not require null pointers to be at the machine's address zero. HOWEVER, casting a 0 constant to a pointer value must result in a NULL pointer (§6.3.2.3/3), and evaluating the null pointer as a boolean must be false. This can be a bit awkward if you really do want a zero address, and NULL is not the zero address.

Nevertheless, with (heavy) modifications to the compiler and standard library, it's not impossible to have NULL be represented with an alternate bit pattern while still remaining strictly conformant to the standard library. It is not sufficient to simply change the definition of NULL itself however, as then NULL would evaluate to true.

Specifically, you would need to:

• Arrange for literal zeros in assignments to pointers (or casts to pointers) to be converted into some other magic value such as -1.
• Arrange for equality tests between pointers and a constant integer 0 to check for the magic value instead (§6.5.9/6)
• Arrange for all contexts in which a pointer type is evaluated as a boolean to check for equality to the magic value instead of checking for zero. This follows from the equality testing semantics, but the compiler may implement it differently internally. See §6.5.13/3, §6.5.14/3, §6.5.15/4, §6.5.3.3/5, §6.8.4.1/2, §6.8.5/4
• As caf pointed out, update the semantics for initialization of static objects (§6.7.8/10) and partial compound initializers (§6.7.8/21) to reflect the new null pointer representation.
• Create an alternate way to access true address zero.

There are some things you do not have to handle. For example:

int x = 0;
void *p = (void*)x;

After this, p is NOT guaranteed to be a null pointer. Only constant assignments need be handled (this is a good approach for accessing true address zero). Likewise:

int x = 0;
assert(x == (void*)0); // CAN BE FALSE

Also:

void *p = NULL;
int x = (int)p;

x is not guaranteed to be 0.

In short, this very condition was apparently considered by the C language committee, and considerations made for those who would choose an alternate representation for NULL. All you have to do now is make major changes to your compiler, and hey presto you're done :)

As a side note, it may be possible to implement these changes with a source code transformation stage before the compiler proper. That is, instead of the normal flow of preprocessor -> compiler -> assembler -> linker, you'd add a preprocessor -> NULL transformation -> compiler -> assembler -> linker. Then you could do transformations like:

p = 0;
if (p) { ... }
/* becomes */
p = (void*)-1;
if ((void*)(p) != (void*)(-1)) { ... }

This would require a full C parser, as well as a type parser and analysis of typedefs and variable declarations to determine which identifiers correspond to pointers. However, by doing this you could avoid having to make changes to the code generation portions of the compiler proper. clang may be useful for implementing this - I understand it was designed with transformations like this in mind. You would still likely need to make changes to the standard library as well of course.

Solution 2:

The standard states that an integer constant expression with value 0, or such an expression converted to the void * type, is a null pointer constant. This means that (void *)0 is always a null pointer, but given int i = 0;, (void *)i need not be.

The C implementation consists of the compiler together with its headers. If you modify the headers to redefine NULL, but don't modify the compiler to fix static initialisations, then you have created a non-conforming implementation. It is the entire implementation taken together that has incorrect behaviour, and if you broke it, you really have no-one else to blame ;)

You must fix more than just static initialisations, of course - given a pointer p, if (p) is equivalent to if (p != NULL), due to the above rule.

Solution 3:

If you use the C std library, you'll run into problems with functions that can return NULL. For example the malloc documentation states:

If the function failed to allocate the requested block of memory, a null pointer is returned.

Because malloc and related functions are already compiled into binaries with a specific NULL value, if you redefine NULL, you won't be able to directly use the C std library unless you can rebuild your entire tool chain, including the C std libs.

Also because of the std library's use of NULL, if you redefine NULL before including std headers, you might overwrite a NULL define listed in the headers. Anything inlined would be inconsistent from the compiled objects.

I would instead define your own NULL, "MYPRODUCT_NULL", for your own uses and either avoid or translate from/to the C std library.

Solution 4:

Leave NULL alone and treat IO to port 0x0000 as a special case, maybe using a routine written in assembler, and thus not subject to standard C semantics. IOW, don't redefine NULL, redefine port 0x00000.

Note that if you're writing or modifying a C compiler, the work required to avoid dereferencing NULL (assuming that in your case the CPU isn't helping) is the same no matter how NULL is defined, so it's easier to leave NULL defined as zero, and make sure that zero can't ever be dereferenced from C.