NULL pointer dereferencing - behaviour

[Andrey Tarasevich]

...
Look at the definition of the "offsetof" macro in whatever C/C++
compiler you use.

So? The implementation of the standard library is not limited by the
bounds of correct C++ language. Furthermore, there is absolutely no
requirement that the standard library is implemented in C++. It could be
implemented in assembly language or in Fortran, for example. You saw an
implementation that dereferences a null pointer? The only thing that
follows from that is that the library that you saw is not implemented in
C++. It is implemented in some language that probably [very] closely
resembles C++ (that's why you got confused by it), but is not C++.
Therefore, your example with 'offsetof' is not relevant.

It is obviously dereferencing a null pointer. It is not making use of
the <b>value</b> of the dereference. There is a suble difference.

Sorry, but C++ language's idea of "use" (of the value of the
dereference) is different from yours.

 

[Andrey Tarasevich]

Does the C++ standard define what should happen in case of NULL pointer
dereferencing. If not, does it say that it is illegal?

Where, if so, does it say it?

In the current version of the standard dereferencing null pointer leads
to undefined behavior. Although there some places in the standard that
seem to be worded incorrectly, which may lead the reader to believe that
in some situations dereferencing null pointer is OK (see for example,
the quite from 'typeof' specification in
http://www.comeaucomputing.com/iso/cwg_active.html#232).

However, the existing developments in the area of C++ specification
(once again, see DR#232) seem to suggest that in the future
dereferencing of a null pointer will be allowed as long as the resultant
lvalue is not used as (converted to) an rvalue. I.e. the behavior of
following code

int* p = NULL;
int* q = &*p;

, which is undefined in the current language specification, will
probably become defined in the future.

 

[Rolf Magnus]

pointer dereferencing.

Yes.

Actually, no.

It says what happens is undefined.

Yes, so IOW, it doesn't define what happens.

 

[Keith P. Boruff]

The introduction of a null pointer constant represented by a reserved word
("nullptr") will hopefully resolve all the confusion caused by "should I
use NULL or 0 for pointers", since it will make a clear distinction
between the two.

That sounds interesting. It would virtually put to rest what's probably the
most popular topic in C++ discussion forums (for better or worse).

Of the two (NULL or 0), I've always used 0? Why? It's portable! No matter
what compiler I use or what header file inclusion combo I use, IT ALWAYS
COMPILES!

The ancient code I'm working on now has lots of NULL "macros" defined in
many, many places (blecchh). Whenever I come across a module littered with
these nasty things, I zap them with a global replace in emacs to 0.

There's one advantage I see to NULL. Doing searches for "NULL" will yield
more relevant results than searches for 0 obviously. However, I believe
that portability is a better trade off.

The conversion will still exist (since the introduction
cannot break zillions of tons of code already written to use 0), but many
good things are going to come out of it. You can read more about it in
the document SC22/WG21/N1601 J16/04-0041.

Speaking of backward compatibility, I'm also dealing with test statements of
checking for a null pointer after executing a new by inserting the
(nothrow) within the operation.

Keith

 

[Andrey Tarasevich]

...
Of the two (NULL or 0), I've always used 0? Why? It's portable! No matter
what compiler I use or what header file inclusion combo I use, IT ALWAYS
COMPILES!

'NULL' is as portable as '0' in the formal meaning of the term
"portable". The only thing you gain by using '0' is that you don't have
to include the corresponding header file. But frankly I don't see any
benefit in that.

The ancient code I'm working on now has lots of NULL "macros" defined in
many, many places (blecchh). Whenever I come across a module littered with
these nasty things, I zap them with a global replace in emacs to 0.

That's the problem of the code. User code is not supposed to define it's
own 'NULL' macro. It is supposed to use the definition provided by the
standard library. I don't know why you chose to replace 'NULL's with
'0's instead of simply removing the user's definitions and including the
proper header instead.

There's one advantage I see to NULL. Doing searches for "NULL" will yield
more relevant results than searches for 0 obviously. However, I believe
that portability is a better trade off.

I find your idea of "portability" to be rather strange.

 

[Keith P. Boruff]

Andrey Tarasevich wrote:

That's the problem of the code. User code is not supposed to define it's
own 'NULL' macro. It is supposed to use the definition provided by the
standard library. I don't know why you chose to replace 'NULL's with
'0's instead of simply removing the user's definitions and including the
proper header instead.

I do remove the NULL definition along with the NULLs. And.. I don't add a
header file because adding a header file for one stupid constant causes
unneeded coupling.

I find your idea of "portability" to be rather strange.

Shrug.

Adding an entire header file just for NULL? That isn't strange?

 

[Peter Koch Larsen]

I'm sure you know much more about the language than me. I thought the
"grey area" was legal .... (Falling back on the reasoning that the
dereferenced data is not actually accessed -- we're just playing around
with its address).
You're probably right ....

You are always allowed to write code with undefined behaviour, but in this
case you trust a particular environment/compiler to give you some guarantees
not part of the standard. The bottomline is that it is still undefined
behaviour and thus not portable. This is especially troublesome in case you
might consider using your code with different compilers - or just upgrading
your compiler. Those who write the standard library for such a compiler have
a greater liberty than the rest of us.

/Peter

 

[Andrey Tarasevich]

I do remove the NULL definition along with the NULLs. And.. I don't add a
header file because adding a header file for one stupid constant causes
unneeded coupling.
...
Adding an entire header file just for NULL? That isn't strange?

That's just how things are done in C++. If you want to make sure that
things that have to be defined identically in different translation
units are indeed defined identically in different translation units, you
put the definitions in the header file and #include it wherever it is
needed. How much stuff you heave defined in that header file is not
really relevant.

Besides, I don't really see how the inclusion of a standard library
header file creates "unneeded coupling".

 

[Keith P. Boruff]

That's just how things are done in C++. If you want to make sure that
things that have to be defined identically in different translation
units are indeed defined identically in different translation units, you
put the definitions in the header file and #include it wherever it is
needed. How much stuff you heave defined in that header file is not
really relevant.

I'm working on a project that includes an excess of 500 files. Are you
saying that I should include the proper header file in each of these (or
most) just for the benefit of NULL? Nope! Take out the old header file with
the homegrown defined NULL, change the NULL references to 0. End of story.

Besides, I don't really see how the inclusion of a standard library
header file creates "unneeded coupling".

If I were to go ahead and add this std header file in all the applicalble
modules on my project, I'd quickly piss off a lot of people on my team
because they'd have to do needless re-builds... and for what? NULL?

Granted, some rebuilds have been necessary as a result of me zapping NULL
but it's a one time thing then it's done.

This is an old, old argument. I'm not going to convince you and you're not
going to convince me. All I can say is that if I ever work from you, I'd
have to use NULL. If you worked for me, you'd have to use 0.

Keith

 

[Andrey Tarasevich]

I'm working on a project that includes an excess of 500 files. Are you
saying that I should include the proper header file in each of these (or
most) just for the benefit of NULL? Nope! Take out the old header file with
the homegrown defined NULL, change the NULL references to 0. End of story.
...

Firstly, I don't really see the difference between 'NULL' and any other
component of the standard library. You have to include the proper header
file to use 'std::vector', 'malloc' or 'size_t', don't you? These
entities belong to rather generic level, which means that they will be
'#include'd virtually everywhere. How is that different from including
the proper header file for 'NULL'?

Secondly, there's no dedicated header file "just for NULL" in the
standard library. All header files that define 'NULL' also define
something else, like 'size_t' and 'ptrdiff_t'. Do you also avoid using
'size_t' for the same reason?

If I were to go ahead and add this std header file in all the applicalble
modules on my project, I'd quickly piss off a lot of people on my team
because they'd have to do needless re-builds... and for what? NULL?

Granted, some rebuilds have been necessary as a result of me zapping NULL
but it's a one time thing then it's done.

Exactly as it is with inclusion of the header file for 'NULL'! "It is
one time thing and then it's done". Once again, I don't see the difference.

This is an old, old argument. I'm not going to convince you and you're not
going to convince me. All I can say is that if I ever work from you, I'd
have to use NULL. If you worked for me, you'd have to use 0.

I'm just trying to find out whether your position is dogmatic or based
on some kind of logic. So far it appears to be purely dogmatic. Under
these circumstances I don't expect to convince you in anything.

 

[Keith P. Boruff]

So far it appears to be purely dogmatic. Under these circumstances I don't
expect to convince you in anything.

ok.

 

[Jack Klein]

Does the C++ standard define what should happen in case of NULL pointer

There is no such thing as a NULL pointer in C++. There are 'null
pointers', and there is the macro NULL, but you can't have a pointer
to a macro. If you initialize a pointer with the macro NULL, or
assign the macro NULL to a pointer, the result is a 'null pointer'.

dereferencing. If not, does it say that it is illegal?

Dereferencing a null pointer is specifically undefined behavior. You
have left the land of C++, and the language does know or care what
happens after that, you are on your own.

Where, if so, does it say it?

Section 1.9 Program execution, paragraph 4 of the ISO C++ standard:

"Certain other operations are described in this International Standard
as undefined (for example, the effect of dereferencing the null
pointer). [Note: this International Standard imposes no requirements
on the behavior of programs that contain undefined behavior. ]"

 

[Rolf Magnus]

'NULL' is as portable as '0' in the formal meaning of the term
"portable". The only thing you gain by using '0' is that you don't have
to include the corresponding header file.

No, there is another thing: You see that it's just 0. NULL is defined to be
0 or something equivalent, but fools you into thinking it's pointer
specific, but it will also work in an integer context. Think of a classic
example:

void foo(int);
void foo(const char*);
....
foo(NULL);

Now guess which one gets called.

That's the problem of the code. User code is not supposed to define it's
own 'NULL' macro.

Actually, even Stroustrup recommends to define your own NULL (not as a macro
though) if you really think you have to use NULL at all.

It is supposed to use the definition provided by the standard library. I
don't know why you chose to replace 'NULL's with '0's instead of simply
removing the user's definitions and including the proper header instead.

Probably because NULL has no benefit over 0.

I find your idea of "portability" to be rather strange.

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

 

[Rolf Magnus]

I'm just trying to find out whether your position is dogmatic or based
on some kind of logic. So far it appears to be purely dogmatic.

I haven't seen any logical argument from you either.

 

[Andrey Tarasevich]

...

I haven't seen any logical argument from you either.
...

So far I was just trying to understand the logic behind the other
poster's position. I already presented my "logical argument" several
times: when it comes to header inclusion, there's absolutely no
difference between 'NULL' and any other entity from the standard
library, which brings us to the following extremely logical questions.
Does my opponent hold the same position with respect to other entities
from the standard library? If not, why 'NULL' was singled out? He didn't
answer these questions. All he could offer were statements of "change
the NULL references to 0. End of story" and "If you worked for me, you'd
have to use 0" kind. I call that dogmatic.

 

[Ron Natalie]

I know that in C++ the use of NULL is almost deprecated.
Hardly.

Stroustrup suggests to prefer 0, because no object is allocated at the
address 0.

He said that a long time ago. The issue he brings up (misdefinition of
the C++ NULL) I haven't seen even on the most odious compilers in recent
memory.

Moreover, I don't think that exists a standard behaviour about Null
pointer deferencing.

There exists such, it is right in the definition of UNDEFINED BEHAVIOR
in the standard.

It's something that happens at run time and a C++ compiler has no
control on it (IMHO).

Whicih is typical of undefined behavior.

 

[Ron Natalie]

He's wrong (if he actually suggests it for that reason). The constant
zero assigned or compared to a pointer is evaluated as a null pointer,
whatever value that has in that implementation (it might actually be all
bits set, or a 'trap' value). An implementation can put objects at an
address of zero if it likes.

Stroustrup never said that...take it easy. What he was saying is that
many implementations (at the time) misdefined NULL to have a pointer
cast integral with it which obviously won't work in C++.

The argument is spurious today.

 

[Ron Natalie]

What is your point? Do you not understand the word "undefined"?
Your program has at least two reasons for undefined behaviour. The
first is declaring 'main' "void".

Actually, that's ill-formed.

Yeah, one of those insidious features of undefined behavior is that
things appear to work (at least today) the way you expect./

 

[Ron Natalie]

How about this:

Look at the definition of the "offsetof" macro in whatever C/C++
compiler you use.
It is obviously dereferencing a null pointer. It is not making use of
the <b>value</b> of the dereference. There is a suble difference.

An implementation is free to do what it wants under the covers.

There is NO GUARANTEE in the standard what happens with any sort
of NULL pointer dereference.

 

[Chris Croughton]

Stroustrup never said that...take it easy.

Not having access to everything he has ever said, I wouldn't like to

What he was saying is that
many implementations (at the time) misdefined NULL to have a pointer
cast integral with it which obviously won't work in C++.

That's the one I know he said (or at least wrote about). I think that a
similar argument can be made that NULL looks as though it is a null
pointer, but will fail for instance when passed to a function using
varargs:

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.)

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...

Chris C