NULL Define - Why?

[Davros]

I understand that I should not be use the NULL #define, rather I should set null pointers to zero explicitly. This is because, on some systems, NULL may not be defined to be zero.

My question is this. If, on such systems, NULL is not zero, what on earth is it defined as? Also, what would be the purpose of defining it to be something other than zero?

[datainjector]

I dont know what u mean by NULL isnt defined as zero .NULL is always defined as zero.NULL is guaranteed to be 0, but the null pointer isnt..

[Davros]

OK. What's the difference between:

void* ptr = NULL;

and

void* ptr = 0;

I seem to recall that the first method is not univerally a good idea.

[Magos]

You should always stick to NULL rather than 0.
Perhaps someone in the future realizes that it is better and more practical that the NULL pointer have the value 47 instead of 0 (whyever that would happen, but imagine). Then you have to modify your code if you used 0, but not if you used NULL.

[Davros]

>You should always stick to NULL rather than 0.

I have always used NULL, but recall reading several articles in which it is suggested that 0 should always be used. There was even a post on this board a few weeks ago which stated the same thing. May be there is some confusion here.

If I find such a reference/article I'll post it. Otherwise, I'll stick with NULL - thanks for the reply.

[Davros]

Found this:

------------------------------------
NULL #define
Null pointer constant that is compatible with any data object pointer. It is not compatible with function pointers. When a pointer is equivalent to NULL it is guaranteed not to point to any data object defined within the program.
------------------------------------

So it's guaranteed not to point to data, but not guaranteed to be zero.

So what happens if I pass NULL to a library, which was built with a different compiler? My compiler defines NULL to be zero, while the internal to the library, it's something else?

Edit : Just picked up on this also:

"It [NULL] is not compatible with function pointers"

Eh? So what do I set function pointers to when they don't point to anything? I've always set them to NULL also?

[Magos]

http://bit.csc.lsu.edu/tutorial/ten-commandments/c-faq/c-1.html

1.3: What is NULL and how is it #defined?
As a matter of style, many people prefer not to have unadorned 0's scattered throughout their programs.For this reason, the preprocessor macro NULL is #defined (by <stdio.h>or <stddef.h>), with value 0 (or (void *)0, about which more later).A programmer who wishes to make explicit the distinction between 0 the integer and 0 the null pointer can then use NULL whenever a null pointer is required.This is a stylistic convention only; the preprocessor turns NULL back to 0 which is then recognized by the compiler (in pointer contexts) as before.In particular, a cast may still be necessary before NULL (as before 0) in a function call argument.(The table under question 1.2 above applies for NULL as well as 0.)

NULL should only be used for pointers; see question 1.8.

[Polymorphic OOP]

The standard states that NULL IS defined as 0 so you don't have to worry about that, however, NULL is only defined if you include certain headers and it's not a direct part of the language. Stroustrup recommends that you don't use NULL, but rather, you use 0 instead, as it is more clear and doesn't risk someone else defining NULL as another value in a different header.

[Hunter2]

Then in that case, would it work if you just put this at the top of your file:

#ifdef NULL
#undef NULL
#define NULL 0
#endif

Doesn't look beautiful and I've never seen it in any other code, but wouldn't that eliminate the risk of somebody defining NULL as something else?

[Stoned_Coder]

as far as im aware in C++ NULL is defined as 0 but in C NULL is a pointer to void.

[Hunter2]

NULL is a pointer to void

Void as in the void (like the type or something), or just void as in nothing?

[Sebastiani]

No, void* as opposed to the integer 0. As far as I know, it's all a matter of taste. I used to always use NULL but have switched to simply 0 because it catches my eye better, honestly (color-coded IDES and all). But yeah, suppose a system was to come about that required an empty pointer to be some other value. Who cares? We end up rewriting everything anyway, why bother with the portability of such conventions? I know that Windows exe's reserve a specific spot in the exe image for the pointer to face, it may even be the 0th offset of a certain section. But I'd be willing to bet that will never change. After all, what would we do with ourselves if we could no longer write "if( handle )..." ?

[master5001]

According to the c standard you would define NULL as ((void *)0) whereas, the more type sensitive C++'s standard calls for NULL to be defined as 0. I'm sure this is what they were talking about. NULL is different in C than it is in C++.

[Polymorphic OOP]

Originally posted by Hunter2
Then in that case, would it work if you just put this at the top of your file:

#ifdef NULL
#undef NULL
#define NULL 0
#endif

Doesn't look beautiful and I've never seen it in any other code, but wouldn't that eliminate the risk of somebody defining NULL as something else?

Yes, that would work, but that misses the point that if someone defined it to be something other than 0 then they did so for a reason and you really shouldn't be changing it.

Anyways, it doesn't really make sense to do that when setting it to 0 makes it directly apparent of what you are trying to do. It's a matter of taste, but using 0 makes it more clear. Why use a macro that's not a direct part of the language when you can more easily just use 0?

Stroustrup gives his reasoning on why he prefers 0 over NULL and it's pretty similar to everything I said. Both will work, but 0 is generally safer. While NULL is defined to be 0 in the standard headers, someone else might choose to define it differently. It's silly to take that chance when 0 accomplishes what you want and provides a more exact representation to other programmers of what you are doing.

[Magos]

Originally posted by Polymorphic OOP
Anyways, it doesn't really make sense to do that when setting it to 0 makes it directly apparent of what you are trying to do. It's a matter of taste, but using 0 makes it more clear. Why use a macro that's not a direct part of the language when you can more easily just use 0?

Stroustrup gives his reasoning on why he prefers 0 over NULL and it's pretty similar to everything I said. Both will work, but 0 is generally safer. While NULL is defined to be 0 in the standard headers, someone else might choose to define it differently. It's silly to take that chance when 0 accomplishes what you want and provides a more exact representation to other programmers of what you are doing.

No offense, but that's just silly. With that reasoning you should scrap all macros and definitions since they can be potentially changed.

I prefer to use NULL since it's more obvious what you're doing, making a pointer into a NULL pointer. By setting it to 0 manually, you can misread and think that you set what it's pointing at to 0.

Get rid of the magic numbers and use definitions instead, it makes the code easier to read and understand.
If you're afraid that NULL has been redefined, define your own MYNULL pointer...