While some of these are great examples of common pitfalls with 64 bits errors, I find it amusing that the first example has a deeper conceptual problem: You can't (shouldn't) use memset to assign NULL to a pointer variable. In many (maybe most) implementations the address 0 is used by the implementation for NULL pointers but the standard allow any number (that can't be a valid address). The compiler automatically converts both 0 and NULL to the proper number when assigned to a pointer; but setting all bytes to 0 (as with memset) only works in the implementations that actually use address 0 for NULL pointers.
I was under the impression that NULL is required to be zero by the standard by now. If still not, it's high time that they give up! Differences like this between theory and practice do not go away easily. The decision is changing which one is easier, the culture or the rule...
It hasn't, and it won't, because a definition of NULL as "all-bits-zero" would be inconvenient for some embedded systems, where I/O ports or interrupt vectors are mapped at low addresses.
There are two separate NULLs. In C for instance a pointer with the value 0 is a "null pointer". This is a language construct. When a compiler sees this construct it knows to use whatever it thinks is best to represent a null pointer on the target architecture (which may not be the same thing as a representation of the value 0).
