   Are 0 pointers unsafe?
  Is the following lines unsafe on a 64-bit architecture?Object *pObj = 0;Shouldn't 0 be interpreted as a 64-bit one?   
  Uh. What?   ;  The literal "0" is convertable to whatever the internal representation of a "Null pointer" is.Internally, a computer could be using 0xBAADF00D as the "null pointer" identfier, and on such a computer, your code (as is) would assign pObj to a value of 0xBAADF00D.That's just the magic of literal 0.   ;  Well, I've been told that it would be a problem on a 64-bit environment since the pointer would be 64-bit and the constant 32-bit. But I'm not pretty sure that what they said is right (maybe they are, I don't know!).EDIT: sorry Hodgman, I started writing this post before you posted yours.Quote:Original post by HodgmanThe literal "0" is convertable to whatever the internal representation of a "Null pointer" is.Internally, a computer could be using 0xBAADF00D as the "null pointer" identfier, and on such a computer, your code (as is) would assign pObj to a value of 0xBAADF00D.That's just the magic of literal 0.So you mean that my code is not unsafe at all?   ;Quote:Original post by andrew1bWell, I've been told that it would be a problem on a 64-bit environment since the pointer would be 64-bit and the constant 32-bit. But I'm not pretty sure that what they said is right (maybe they are, I don't know!).For this to be true you'd have to write:Object *pObj;( *reinterpret_cast<int32*>(&pObj) ) = 0;Quote:Original post by andrew1bSo you mean that my code is not unsafe at all?Yes, when assigning a pointer to 0, it doesn't mean "the internal representation of the 32-bit number 0", it means "the internal representation of a NULL pointer".Same goes for:float f = 0;//0 means internal representation of 32 bit float zerochar c = 0;//8 bit zeroshort s = 0;//16 bit zerolong long l = 0;//64 bit zeroObject* p = 0;//NULL pointer (may not actually be the number 0);  Thanks. That's quite annoying because many people say that NULL is safer than 0. On the other hand, Stroustrup himself recommends 0 (http://www2.research.att.com/~bs/bs_faq2.html#null).   ;  Strictly speaking, NULL is a C artifact and has no real place in C++. Realistically speaking, I like the clarify NULL brings. The nullptr proposal was an excellent idea I thought, and I believe it's been added to C++0x.   ;Quote:Original post by PromitStrictly speaking, NULL is a C artifact and has no real place in C++. Realistically speaking, I like the clarify NULL brings. The nullptr proposal was an excellent idea I thought, and I believe it's been added to C++0x.Agreed. Check out this link for more  info ;Quote:Original post by kensheeQuote:Original post by PromitStrictly speaking, NULL is a C artifact and has no real place in C++. Realistically speaking, I like the clarify NULL brings. The nullptr proposal was an excellent idea I thought, and I believe it's been added to C++0x.Agreed. Check out this link for more  info I believe that you have mistakenly copied this topic's URL to the link you’ve just posted.   ;Quote:Original post by HodgmanYes, when assigning a pointer to 0, it doesn't mean "the internal representation of the 32-bit number 0", it means "the internal representation of a NULL pointer".I don't think that's something you can rely on, or at least depends on compiler implementation, I have seen instances where a comparison breaks because NULL!=0 (I think this was on MinGW GCC), this usually happens on debug builds where the compiler sets NULL to the aforementioned 0x0BADFOOD in order to easily distinguish between null pointers and the zero value in memory.So, I agree with Promit, For clarity and safety, use NULL when you mean NULL.