> 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.

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.).

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.

> It's another good example that shows that even plain C is not an > easy/simple language as soon as you look into details.

I think the language itself could be easy, but politics are poisoning all standards.

> 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

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.

> The compiler must opaquely translate C null-pointers to the machine's > internal null-pointer and vice versa.

again, there is no such thing like a machines null pointer

> According to this answer in the comp.lang.c FAQ, the null-pointer should > always effectively evaluate as false in boolean expressions regardless

that's the point

> 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...

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.

> 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.

Many teachers are not up to date. They often live in their own isolated world. So don't take them too seriously :-)

> 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.

probably this was a pre ansi compiler. Or it was an academical curiosity.