How to define NULL using #define

Question

I want to redefine NULL in my program such as

#define MYNULL ((void*)0)

But this definition is not working in the following statement:

char *ch = MYNULL;

Error : can not convert from void* to char *

What would be the best way to define NULL?

Answer 1

#define MYNULL 0

will work in C++

Answer 2

#define MYNULL NULL

is the safest, I see no reason in doing so but if you really want to, go ahead. Here's how C and C++ do it respectively:

#define NULL 0 //C++
#define NULL ((void*)0) //C

Generally speaking, defining 0 for NULL is a bad habit, you actually want it to be part of the language. C++0x adresses this.

This is what Bjarne Stroustrup has to say on this:

Should I use NULL or 0?

In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer. In pre-standard code, NULL was/is sometimes defined to something unsuitable and therefore had/has to be avoided. That's less common these days. If you have to name the null pointer, call it nullptr; that's what it's going to be called in C++0x. Then, "nullptr" will be a keyword.

Answer 3

#ifdef __cplusplus
#define MYNULL 0
#else
#define MYNULL ((void*)0)
#endif

will work in both of them.

Answer 4

What exactly is the problem with getting your NULL from where you're supposed to?, i.e.,

#include <stddef.h>

or

 #include <cstddef>

as alluded to in @Johannes Rudolph's answer, any trickery you do is not likely be very future proof in the face of things like nullptr etc.

EDIT: while stdlib (and many others) are mandated to include a NULL, stddef is the most canonical header [and has been for decades].

PS In general, it's just a bad idea to get involved in this sort of trickery unless you have a really good reason. You didnt expand on the thinking that led you to feeling the need to do this. If you could add some detail on that, it's likely to lead to better answers. Other people answering the question should have pointed this out in their answers too, but I guess does FGITW as FGITW does best :D

EDIT 2: As pointed out by @Yossarian: The single justification for doing this is if there isnt a NULL defined in an appropriately language-agnostic form elsewhere in your system. Naked compilers with no headers and/or if you're writing your own custom standard library from scratch are examples of such a circumstance. (In such a bare-bones scenario, I'd go with @lilburne's answer (be sure to use 0 as much as possible))

Answer 5

I think that anyone that doesn't know that setting a pointer in C/C++ to 0 is the same as setting it to NULL, nullptr, or any other equivalent shouldn't be messing with code. The difference in readability between

char* ch = NULL

and

char* ch = 0;

is minimal. When it comes to expressions the forms

if (NULL == ch) {
}
if (0 == ch) {
}
if (nullptr == ch) {
}

are no more readable than

if (!ch) {
}

Answer 6

In contrast to what some people state here, 0 is a perfectly valid definition for NULL in C. Thus you have to be careful when you give NULL as an argument to a variadic function, because it may be mistaken as the integer value 0, ending in non-portability.

http://c-faq.com/null/null2.html

BTW, the comp.lang.c FAQ is a highly recommended read for every C programmer. See for example here:

http://c-faq.com/null/null1.html

containing such gems of nearly-forgotten wisdom like "As mentioned above, there is a null pointer for each pointer type, and the internal values of null pointers for different types may be different." Which means that calloc or memset are NOT a portable initialization for pointers.