views:

335

answers:

9

In this question an initializer is used to set a pointer to null. Instead of using value of 0 value of 0L is used. I've read that one should use exactly 0 for null pointers because exact null pointer representation is implementation-specific.

Can using 0L to set a pointer to null cause problems while porting?

+15  A: 

From the standard (4.10.1):

A null pointer constant is an integral constant expression (5.19) rvalue of integer type that evaluates to zero

so I guess 0L is ok.

Andreas Brinck
+3  A: 

I can't give you an exact answer, but regardless of what the exact answer to your question is, just the idea itself of initializing a pointer with 0L is wrong, because it suggests that a pointer is the same size as a long, which is not necessarily true, ofcourse.

Whether the compiler accepts it or not, and whether it's safe or not, I wouldn't do it because it suggests an invalid idea.

Jesper
Does that mean that initialising it with 0 suggests it is the same size as an int? I don't think so.
anon
No, because 0 does not imply an int.
dicroce
@Neil: Even if it does, it's less bad than explicitly saying `0L`, because the `L` strongly suggests that it's supposed to be understood as a `long`. Just `0` doesn't necessarily by itself imply that it's an `int`.
Jesper
I think the fact that you're explicitly saying the value is a long is the problem here.
KernelJ
@KernelJ: Yes, that's exactly what I mean.
Jesper
+2  A: 

The null pointer representation is implementation specific, but neither 0 nor 0L is necessarily that implementation - they are just ways that the user can specify the null pointer, and either is OK.

I should point out that Bjarne Stroustrup has several times indicated that his preference is to use plain 0 (and not NULL).

anon
He has, but in this case I disagree with him. It makes it a lot easier to find your pointer comparisons when you use NULL, instead of overloading 0 to mean either a) a pointer or b) a number. (Note: he recommends using nullptr when that's available, so he's conflicted on this point. He's not recommending 0 so much as recommending against using a macro.) http://www2.research.att.com/~bs/bs_faq2.html
Bill
+13  A: 

I think 0L is fine, except for the fact that it would imply that you believe the pointer type your assigning to is the same size as a long, and so is a bit confusing.

I think using NULL is much more clear.

KernelJ
+1 because NULL is more clear to those maintaining the software. Trust me, I've seen deadbeef and 0 used in the same project.
wheaties
0xDEADBEEF is especially bad. 0 is the only value you can always set a pointer to be (a null pointer), and it doesn't matter what size the pointer is.
KernelJ
NULL is legal and idiomatic. 0 is legal and idiomatic. 0L is legal but not idiomatic. 0xDEADBEEF is either unspecified or undefined, and certainly isn't a null pointer constant. I'm looking forward to `nullptr` myself.
David Thornley
Seven characters for something which is basically a 0 is asking a bit much I think. I can't think why so much verbosity is required, when we have NULL already. Maybe it has some special uses in the new standard but I haven't really looked at it.
KernelJ
Overload resolution. Given `f(int)` and `f(int*)`, `f(NULL)` calls `f(int)` but `f(nullptr)` calls `f(int*)`.
MSalters
Yeah, that's great but... Anyone who overloads functions like that needs to be shot.
KernelJ
A: 

Assignment of 0L, a long integer (64bit) to an 32bit pointer might cause problems. As in the other post mentioned, use NULL to initializse pointers to zero.

Holger Kretzschmar
What problems do you refer to? AFAIK, the compiler will perform the required type conversions.
David Rodríguez - dribeas
The value 0 can be cast to any size of integer from any other.
KernelJ
You are not assigning "a long integer", but "the null pointer constant". And that is guaranteed to work, regardless of the bit width of integers or pointers.
jalf
All of you are right, my thinking was that assignment of 64 bit integers to a 32 bit pointer would be invalid. but as you mentioned the compiler will convert the constant to the required type.
Holger Kretzschmar
+4  A: 

In C++0x there is a new null pointer constant called nullptr of type nullptr_t. It can be implicitly converted to any pointer type.

Until then I would recommend using NULL, however 0 and 0L will both work on every implementation I've ever heard of.

Brian R. Bondy
0 is defined to work in the C++ standard. NULL is just a macro carried over from C.
McPherrinM
defined as 0, still I have a preference to NULL as I personally think it looks cleaner.
Brian R. Bondy
+2  A: 

I would disagree with those who recommend using NULL, though any of the three stated options would indeed work. In idiomatic C++, the standard choice is 0 (perhaps because that's Stroustrup's preference: http://www2.research.att.com/~bs/bs_faq2.html#null).

0L will be implicitly cast to the appropriate pointer type in the same way as 0 would be; it just looks a bit strange and doesn't really make a great deal of sense for the reason Jesper gave..

Nye
I do prefer 0 also, but that is just a matter of taste, I guess.
David Rodríguez - dribeas
Note: Stroustrup recommends using nullptr when that's available, so he's not recommending 0 so much as recommending against using a macro.
Bill
+1  A: 

I would have to agree with everyone that said NULL. To those that prefer using 0, my opinion is that your code should say what it means. The result you want is a null pointer, so your code should say that. It makes even more sense when you do a comparison:

if (some_variable == NULL) { ... }

is much clearer than

if (some_variable == 0) { ... }
Nathan Parrish
I personally prefer `if (!some_variable) { }`
MSalters
+1  A: 

You can use false, 0, 0l, 0L, 0ul, 0u, 00, or any number of ways to represent the literal zero. The literal zero is basically a magical symbol that happens to also correspond to a null pointer constant.

If we were talking about a value that happens to be bitwise zero and the code were memcpy-ing it over the pointer, then we would have the problems mentioned above.

Bonus question: What types have a null pointer constant that isn't bitwise zero?

MSN