[chuck-dev] fixed array compatibility checking (PATCH)

[Robin Haberkorn]

On 06/09/12 09:50, Harald wrote:
> ...
> 
> so IMHO
> - NULL not being a zero value is pre-ANSI C (btw. that's my generation)
> - if(pointer)  is C++ and C standard compliant (conversion to bool)
> - NULL is not sufficient in many other cases (like overloaded function
> selection) and in no way better than 0
>   here we have to use (CLASS*)0 instead, with the correct CLASS
> - in C++ NULL is usually explicitly defined as 0 whereas in C (#ifndef
> __cplusplus) it is defined as (void*)0,
>   please look in mixed headers
> _______________________________________________

Ok, after researching the subject I have to admit that you are basically
right though the matter is not as easy as you or I thought.
It's another good example that shows that even plain C is not an
easy/simple language as soon as you look into details.

The machine's null-pointer *address* is in fact undefined. There are
machines where the 0-address is valid or another bit-pattern is used for
some reason...
In C(++), the null-pointer constant is always zero and the NULL macro
and can be defined in different ways but only regarding the type it
yields (void *, int, long) whereas it must always be zero-valued. The
definition of NULL as ((void*)0) is only allowed and common in plain C.
The compiler must opaquely translate C null-pointers to the machine's
internal null-pointer and vice versa.

According to this answer in the comp.lang.c FAQ, the null-pointer should
always effectively evaluate as false in boolean expressions regardless
of its actual value:
http://c-faq.com/null/ptrtest.html
In plain C at least, this has nothing to do with the semantics of
casting to the boolean type which does not even exist (prior to C99).
AFAIK the type of boolean expressions is still int even in C99.

Because of the confusion surrounding null-pointers in C(++), I would
still consider it good coding style to explicitly compare with NULL, but
who cares...

My own confusion stemmed from the fact that I once argued with a teacher
who told me he used a Windows C compiler where NULL was defined
differently and the null-pointer test did not work as expected.
Apparently the compiler he was using is broken or the NULL macro was
redefined somewhere else - a condition which can indeed result in such
unexpected behaviours (and much confusion) as you can easily try out
yourself.

Best regards,
Robin