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

[Harald]

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-dev/attachments/20120907/9362d4e0/attachment.htm>