NULL pointer dereferencing - behaviour

[BigMan]

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?

[Andrey Tarasevich]

ajitho wrote:

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

--
Best regards,
Andrey Tarasevich

[Andrey Tarasevich]

BigMan wrote:

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.

--
Best regards,
Andrey Tarasevich

[Rolf Magnus]

Noah Roberts wrote:

BigMan wrote:

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

Yes.

Actually, no.
It says what happens is undefined.

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

[Keith P. Boruff]

Victor Bazarov wrote:

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]

Keith P. Boruff wrote:

...
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 "portabilit y" to be rather strange.

--
Best regards,
Andrey Tarasevich

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

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 "portabilit y" to be rather strange.

Shrug.

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

[Peter Koch Larsen]

"ajitho" <aj************ @yahoo.com> skrev i en meddelelse
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

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]

Keith P. Boruff 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.
...
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".

--
Best regards,
Andrey Tarasevich

[Keith P. Boruff]

Andrey Tarasevich wrote:

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.

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]

Keith P. Boruff wrote:

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

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?

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.

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.

--
Best regards,
Andrey Tarasevich