[chuck-dev] fixed array compatibility checking (PATCH)
hg42 at gmx.net
Fri Sep 7 16:46:28 EDT 2012
> 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
> 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
> 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
> 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 >
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
> 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 >
probably this was a pre ansi compiler. Or it was an academical curiosity.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the chuck-dev