<p>> 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.</p>
<p>well C and C++ is a mess when it comes to standards. Most critical things are defined as undefined, instead of finding a proper definition. I think it's because some companies are involved, which don't want to change their proprietary super-duper-compilers (MS etc.).</p>

<p>My main point was, that if(pointer) is probably more defined (for C++) than if(pointer == NULL), because conversion of null pointer to bool is explicitly defined.</p>
<p>> It's another good example that shows that even plain C is not an > easy/simple language as soon as you look into details.</p>
<p>I think the language itself could be easy, but politics are poisoning all standards.</p>
<p>> 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</p>
<p>at the end, "null pointer" is just a definition. The machine/cpu doesn't have such a thing. It's simply nice to have a pointer value which isn't used anyway.</p>
<p>> The compiler must opaquely translate C null-pointers to the machine's > internal null-pointer and vice versa.</p>
<p>again, there is no such thing like a machines null pointer</p>
<p>> According to this answer in the comp.lang.c FAQ, the null-pointer should > always effectively evaluate as false in boolean expressions regardless</p>
<p>that's the point</p>
<p>> 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...</p>
<p>I think we have to distinguish C and C++. They have different definitions and different sights. That's why the NULL constant is usually defined different.</p>
<p>> 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.</p>

<p>Many teachers are not up to date. They often live in their own isolated world. So don't take them too seriously :-)</p>
<p>> 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.</p>

<p>probably this was a pre ansi compiler. Or it was an academical curiosity.</p>