NULL pointer dereferencing - behaviour

[Rolf Magnus]

printf("%p\n", NULL);

will not have the expected effect on systems where pointers are not
identical in representation to ints. Whereas if NULL is not used,

printf("%p\n", 0);

is obviously wrong. (In real code it's unlikely to be printf(), no one
is likely to want to print the value of an explicitly null pointer, but
there are other functions where the same effect occurs.)

Yes, and there is also the argument about overloaded functions (see my other
posting), where one function takes an int and the other a pointer. If you
call it with NULL as argument, it's the int version that is called, not (as
one might be fooled into expecting) the pointer version. And this problem
exists on every implementation, not just some, like the varargs problem.

I usually use 0 rather than NULL in C++ code when assigning a null
pointer, but I don't onject strongly to NULL either. It's one of those
style issues...

Yes. That's why the thread is growing so rapidly ;-)

 

[Keith P. Boruff]

Rolf Magnus wrote:

You're right here. I don't see any reason why NULL should be less portable
than 0.

Yeah. I didn't make myself clear enough here, I admit. What I was trying to
say is that with just 0, I don't have to hunt down any header file. Using
0, I know my program will always compile.

That being said, on my compiler, it seems that all I need to do is add one
standard header file and I have NULL.... is this "standard"? I have no
idea.

So, what I thought was a mechanism of convenience (being able to build
something without having to reference what header file NULL is in), ends up
just being a matter of personal style.

NULL is just a tricky thing with me and I prefer to leave it alone. If NULL
were a keyword, then it would be a whole different ballgame.

What I meant by "portability" is that I'm not sure if NULL is embedded in
the standard header file soup. I don't have to second guess with 0.

Again, what I thought was a matter of "portability" is just a matter of
style as NULL is probably a ubiquitous critter these days.

Keith

 

[Clark S. Cox III]

That being said, on my compiler, it seems that all I need to do is add one
standard header file and I have NULL.... is this "standard"?

Yes, it is.

So, what I thought was a mechanism of convenience (being able to build
something without having to reference what header file NULL is in), ends up
just being a matter of personal style.

Yes, it is just that, style, nothing more. As far as the compiler is
concerned, totally NULL and 0 are interchangable. NULL is simply an
easy to recognize identifier, instead of a magic number. Just like
other macros defined by the standard library (EOF, NAN, EXIT_FAILURE,
etc.)

NULL is just a tricky thing with me and I prefer to leave it alone. If NULL
were a keyword, then it would be a whole different ballgame.
What I meant by "portability" is that I'm not sure if NULL is embedded in
the standard header file soup.

It is, NULL is required to be defined if you include any of the
appropriate headers.

I don't have to second guess with 0.

There's no second guessing NULL either.

 

[Keith P. Boruff]

It is, NULL is required to be defined if you include any of the
appropriate headers.

OK but it is possible to create a module that uses no standard header files,
right? What then?

What if by some chance I create a module that has no standard header files
in its dependency chain? You're probably going to get a compiler error if
you use NULL, no? You won't with 0.

This is a contrived situation I admit but it is possible, is it not?

Keith

 

[Clark S. Cox III]

OK but it is possible to create a module that uses no standard header files,
right? What then?

But why would you want to do that?

What if by some chance I create a module that has no standard header files
in its dependency chain? You're probably going to get a compiler error if
you use NULL, no? You won't with 0.
This is a contrived situation I admit but it is possible, is it not?
Keith

Just as possible as trying to use std::cout or std::string without
including any system headers; it just doesn't make sense.

 

[Keith P. Boruff]

Clark S. Cox III wrote:

But why would you want to do that?

You're not answering my question. Are you telling me here that all modules
in C++ have to have standard header files in their dependency chains? I
never read any such thing.

Just as possible as trying to use std::cout or std::string without
including any system headers; it just doesn't make sense.

If I don't need std::cout or std::string or whatever other std:: in a
module, I'm not going to include those "standard" header files. That being
said, I'd have a problem building any module using NULL.

Keith

 

[Karl Heinz Buchegger]

OK but it is possible to create a module that uses no standard header files,
right? What then?

What if by some chance I create a module that has no standard header files
in its dependency chain? You're probably going to get a compiler error if
you use NULL, no? You won't with 0.

This is a contrived situation I admit but it is possible, is it not?

In principle you are right - yes it is possible.
But practice is different. The number of cases where
I wrote some source file without the inclusion of at
least one standard header file bringing in NULL in
the last 20 years can be counted with the fingers of
one hand.

 

[Chris Croughton]

Yes, and there is also the argument about overloaded functions (see my other
posting), where one function takes an int and the other a pointer. If you
call it with NULL as argument, it's the int version that is called, not (as
one might be fooled into expecting) the pointer version. And this problem
exists on every implementation, not just some, like the varargs problem.

Specifically, the ambiguity exists whenever NULL is passed as an
ambiguous parameter in any way.

This is why C defined NULL as (void*)0, so that it is unambiguous -- but
C++ doesn't allow automatic conversion of void* to another pointer type,
so can't do that.

Yes. That's why the thread is growing so rapidly ;-)

Indeed...

Chris C

 

[Ron Natalie]

This is why C defined NULL as (void*)0, so that it is unambiguous -- but
C++ doesn't allow automatic conversion of void* to another pointer type,
so can't do that.

C permits that definition, but it doesn't require it which means you still
better watch your types in printf. However varargs behavior is sufficiently
odious that NULL is the least of your worries.

 

[Rolf Magnus]

C permits that definition, but it doesn't require it which means you still
better watch your types in printf.

C doesn't require different pointer types to have the same representation
and size or to have the same value for a null pointer, however, it requires
that conversion of a null pointer to another pointer type will result in a
null pointer. So for strict conformance, you need to cast NULL to the
expected pointer type before using it as argument in a variable argument
list, no matter whether it's defined as 0 or as (void*)0.

 

[Ron Natalie]

Ron Natalie wrote:




C doesn't require different pointer types to have the same representation
and size or to have the same value for a null pointer, however, it requires
that conversion of a null pointer to another pointer type will result in a
null pointer. So for strict conformance, you need to cast NULL to the
expected pointer type before using it as argument in a variable argument
list, no matter whether it's defined as 0 or as (void*)0.

%p takes a void*.

 

[Rolf Magnus]

%p takes a void*.

Yes, but I thought we agreed that printf("%p", NULL); isn't too useful in
real-life programs. Therefore, I was talking about varargs functions in
general, not printf specifically.