Issue with NULL pointers on Harvard Architecture platform

Question

Interesting issue we came across here this week.

We are working in C on a Harvard Architecture embedded platform, which has 16-bit data addresses and 32-bit code add

Answer 1

The way you describe should work:

6.3.2.3/3 An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.

So, either NULL has been redefined to something not 0 or (void*)0 (or equivalent?) or your compiler is non-conformant.

Try redefining NULL yourself (to plain 0) after all the #includes in all files :-)

just for kicks: try gcc -E (to output the preprocessed source) on a problem file and check the expansion of NULL

Answer 2

You could try a segment hack (really only a hack), so you can use the fast 16bit comparision, without any risk. Create segements at each n*0x10000 boundary with size of 4 (or even smaller), so there never can't exists a real function.

It depends on your embedded device memory space, if this is a good or a really bad solution. It could work if you have 1MB normal Flash, which will never change. It will be painfull if you have 64MB Nand Flash.

Answer 3

It seems to me the easiest way is replace all occurrences of NULL by 0. This works for function pointer (as you say) and object pointers.

This is a variant of (2) Redefine NULL to plain 0.

But the fact that you cannot compare function pointers with NULL is a bug in your implementation. C99 states that comparison of the null pointer constant is possible with both object and function pointers, and that NULL should expand to this constant.

Small addition from the C-FAQ question 5.8:

Q: Is NULL valid for pointers to functions?
A: Yes (but see question 4.13)

Mixing function pointers with (void *) 0

(A reply to R..'s comment). I believe using function pointers and (void *) 0 together is well-defined. In my reasoning I will refer to sections of the C99 draft 1256, but will not quote large parts to keep it readable. It should also be applicable to C89.

• 6.3.2.3 (3) defines the integer constant expression 0 and such an expressions cast to (void *) as null pointer constant. And: "If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function."
• 6.8.9 defines the == and != operands for (among other) a pointer operand and a null pointer constant. For these: "If one operand is a pointer and the other is a null pointer constant, the null pointer constant is converted to the type of the pointer."

Conclusion: In fp == (void *) 0, the null pointer constant is converted to the type of fp. This null pointer can be compared to fp and is guaranteed to be unequal to fp if it points to a function. Assignment (=) has a similar clause, so fp = (void *) 0; is also well-defined C.

Answer 4

You could try this:

#ifdef NULL
  #undef NULL
#endif
#define NULL 0

Answer 5

Here are a few suggestions:

1. temporarily change NULL to (char*)0 or something else that is not implicitly convertible to a function pointer. This should give a warning about every comparison with a non-matching pointer. You could then run the produced compiler output through a tool like grep and look for a typical pattern for function pointers, like (*)(.

2. redefine NULL as 0 (without the cast to void*). This is another valid definition for NULL and might do the right thing for you, but no guarantees.

Answer 6

Edit the implemention's system headers to replace all occurrances of

#define NULL ((void *)0)

with

#define NULL 0

Then file a bug report with the vendor. You should not have to modify your (perfectly correct, albeit ugly style) code because of a bug in the vendor's compiler.