By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,305 Members | 1,843 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,305 IT Pros & Developers. It's quick & easy.

NULL pointer dereferencing - behaviour

P: n/a
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?

Jul 23 '05 #1
Share this Question
Share on Google+
51 Replies


P: n/a
And what if I dereference a pointer to a structure like this:

SturctPtr->Member;

What should happen if StructPtr is NULL and Member is not first in the
structure, i.e. it is alligned at 4 bytes from the beginning?

Jul 23 '05 #2

P: n/a
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?


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

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

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

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

P.S:

Why on the Earth a person should try to dereference (with awareness) a
NULL pointer ???

Bye

Andrea
Jul 23 '05 #3

P: n/a
BigMan wrote:
And what if I dereference a pointer to a structure like this:

SturctPtr->Member;

What should happen if StructPtr is NULL and Member is not first in the
structure, i.e. it is alligned at 4 bytes from the beginning?


The result of dereferencing a null pointer is _undefined_. IOW, anything
can happen and is allowed to happen AFA C++ is concerned. Most modern
operating systems will indicate some kind of exceptional situation and
abort the offending program. But that's not guaranteed.

V
Jul 23 '05 #4

P: n/a

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


Yes.

It says what happens is undefined.

Jul 23 '05 #5

P: n/a
On Tue, 15 Feb 2005 15:09:27 GMT, Andrea Sini <do@notwrite.it> wrote:
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?
I know that in C++ the use of NULL is almost deprecated.

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


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.
Moreover, I don't think that exists a standard behaviour about Null
pointer deferencing.
It's explicitly undefined behaviour, and can cause demons to fly out of
your nose, or World War III, or an asteroid to hit your home town. It
may cause a trap (bus error, interrupt, signal, code dump or whatever)
but it may not (and will not on one of the most common CPU architectures
as well as on some systems under another common architecture).

(As for what happens when one dereferences a derived pointer, like a
structure member, that's even less defined if that's possible, because
many systems won't even trap it...)
It's something that happens at run time and a C++ compiler has no
control on it (IMHO).
Well, a compiler could issue code protecting every memory access...
Why on the Earth a person should try to dereference (with awareness) a
NULL pointer ???


Perhap the OP likes demons flying out of zir nose? I haven't tried it
myself, it might be a turn-on for some people (like banging heads
against a brick wall).

Chris C
Jul 23 '05 #6

P: n/a
#include <stdio.h>

class MyClass {
public:
void A() {
if (this==NULL) printf("NULL Pointer\n");
}
};
void main() {
MyClass *ptr = 0;
ptr->A();
}

Jul 23 '05 #7

P: n/a
Chris Croughton wrote:
On Tue, 15 Feb 2005 15:09:27 GMT, Andrea Sini <do@notwrite.it> wrote:

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?
I know that in C++ the use of NULL is almost deprecated.

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

He's wrong (if he actually suggests it for that reason).


He actually suggests it for a different reason. 'NULL' is a simple macro
that in most implementations (all implementations I've seen) expands into
0. So, by using 'NULL' instead of '0' the programmer is fooling himself
into believing he's using a pointer while really it's just a damn integer
literal. Using '0' instead of a symbol [mis-]representing it is clearer.
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.


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

[...]

V
Jul 23 '05 #8

P: n/a
ajitho wrote:
#include <stdio.h>

class MyClass {
public:
void A() {
if (this==NULL) printf("NULL Pointer\n");
}
};
void main() {
MyClass *ptr = 0;
ptr->A();
}


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

V
Jul 23 '05 #9

P: n/a
#include <stdio.h>

class MyClass {
public:

void A(const MyClass &arg)
{
if (&arg == 0) {
printf("Null reference!\n");
}
}

};
void main() {
MyClass ptr;

ptr.A( *(MyClass *)0);
}

Jul 23 '05 #10

P: n/a
ajitho wrote:
#include <stdio.h>
[..]
void main() {
[.. example of undefined behaviour snipped ..]


Yes, we get it, you know how to reproduce undefined behaviour.
Give it a rest already.
Jul 23 '05 #11

P: n/a
ajitho wrote:
...


What are you trying to demonstrate by posting these already
beaten-to-death examples here? Both code samples you posted so far
produce undefined behavior. Are you trying to say that sometimes
undefined behavior might manifest itself in seemingly predictable
manner? But we all know that. And it is completely irrelevant and
doesn't make any difference.

--
Best regards,
Andrey Tarasevich
Jul 23 '05 #12

P: n/a
ajitho wrote:
http://www.comeaucomputing.com/iso/cwg_closed.html#315


WTF does this have to do with your examples?
Jul 23 '05 #14

P: n/a
ajitho wrote:
http://www.comeaucomputing.com/iso/cwg_closed.html#315


And? Have you tried to follow the link and read the DR#315 yourself?
Have you ever heard about the difference between static and no-static
members of the class?

Also, try reading

http://www.comeaucomputing.com/iso/cwg_active.html#232
http://www.comeaucomputing.com/iso/cwg_active.html#453

linked from DR#315.

In your first example the function is not static. The behavior is
undefined regardless of what the outcome of these still open DRs.

In your second example you are trying to create a null-reference. This
is undefined behavior. And if you read the proposed resolutions in the
above DRs, you'll see that there's no intent whatsoever to legalize
null-references in C++. The behavior is undefined.

--
Best regards,
Andrey Tarasevich
Jul 23 '05 #15

P: n/a
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.

Jul 23 '05 #16

P: n/a
ajitho wrote:
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.


It is also part of the standard library, not user code. The writer of
the standard library can take advantage of knowledge of compiler details
that users cannot portably rely on.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Jul 23 '05 #17

P: n/a

Pete Becker wrote:
ajitho wrote:
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.

It is also part of the standard library, not user code. The writer of

the standard library can take advantage of knowledge of compiler details that users cannot portably rely on.


For example, the X window system defines XtOffset(type, member) in
several different ways. ONE of those ways is ((type*)NULL)->member.
However, it is not the only one, indicating that at least on some
systems that doesn't work as planned.

Of course, that is C code, but I don't think there is a difference in
this case.

Jul 23 '05 #18

P: n/a
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 ....

Jul 23 '05 #19

P: n/a
On Tue, 15 Feb 2005 12:07:59 -0800, Andrey Tarasevich
<an**************@hotmail.com> wrote:
ajitho wrote:
http://www.comeaucomputing.com/iso/cwg_closed.html#315


And? Have you tried to follow the link and read the DR#315 yourself?
Have you ever heard about the difference between static and no-static
members of the class?

Also, try reading

http://www.comeaucomputing.com/iso/cwg_active.html#232
http://www.comeaucomputing.com/iso/cwg_active.html#453

linked from DR#315.

In your first example the function is not static. The behavior is
undefined regardless of what the outcome of these still open DRs.

In your second example you are trying to create a null-reference. This
is undefined behavior. And if you read the proposed resolutions in the
above DRs, you'll see that there's no intent whatsoever to legalize
null-references in C++. The behavior is undefined.


I think it's some weird kind of troll. I thought originally that it was
just confused (which is not an unusual state), but just posting examples
of undefined behaviour is weird...

Chris C
Jul 23 '05 #20

P: n/a
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
Jul 23 '05 #21

P: n/a
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
Jul 23 '05 #22

P: n/a
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.

Jul 23 '05 #23

P: n/a
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

Jul 23 '05 #24

P: n/a
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 "portability" to be rather strange.

--
Best regards,
Andrey Tarasevich
Jul 23 '05 #25

P: n/a
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 "portability" to be rather strange.


Shrug.

Adding an entire header file just for NULL? That isn't strange?
Jul 23 '05 #26

P: n/a

"ajitho" <aj************@yahoo.com> skrev i en meddelelse
news:11**********************@f14g2000cwb.googlegr oups.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
Jul 23 '05 #27

P: n/a
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
Jul 23 '05 #28

P: n/a
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
Jul 23 '05 #29

P: n/a
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
Jul 23 '05 #30

P: n/a
Andrey Tarasevich wrote:
So far it appears to be purely dogmatic. Under these circumstances I don't
expect to convince you in anything.


ok.

Jul 23 '05 #31

P: n/a
On 15 Feb 2005 07:00:33 -0800, "BigMan" <Bi****@abv.bg> wrote in
comp.lang.c++:
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. ]"

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Jul 23 '05 #32

P: n/a
Andrey Tarasevich wrote:
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.


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


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


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

Jul 23 '05 #33

P: n/a
Andrey Tarasevich wrote:
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.

Jul 23 '05 #34

P: n/a
Rolf Magnus wrote:
...
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.
...


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.

--
Best regards,
Andrey Tarasevich

Jul 23 '05 #35

P: n/a
Andrea Sini wrote:
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.
Jul 23 '05 #36

P: n/a
Chris Croughton wrote:
On Tue, 15 Feb 2005 15:09:27 GMT, Andrea Sini <do@notwrite.it> wrote:

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?


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

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

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.
Jul 23 '05 #37

P: n/a
Victor Bazarov wrote:

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./
Jul 23 '05 #38

P: n/a
ajitho wrote:
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.
Jul 23 '05 #39

P: n/a
On Wed, 16 Feb 2005 13:32:57 -0500, Ron Natalie
<ro*@sensor.com> wrote:
Chris Croughton wrote:
On Tue, 15 Feb 2005 15:09:27 GMT, Andrea Sini <do@notwrite.it> wrote:

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?

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

Stroustrup suggests to prefer 0, because no object is allocated at the
address 0.
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.


Not having access to everything he has ever said, I wouldn't like to
make that asertion <g>.
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
Jul 23 '05 #40

P: n/a
Chris Croughton wrote:
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 ;-)

Jul 23 '05 #41

P: n/a
Rolf Magnus wrote:

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.


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
Jul 23 '05 #42

P: n/a
On 2005-02-16 17:58:38 -0500, "Keith P. Boruff" <kb*****@optonline.net> said:
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.
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
cl*******@gmail.com

Jul 23 '05 #43

P: n/a
Clark S. Cox III wrote:
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.


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

Jul 23 '05 #44

P: n/a
On 2005-02-16 18:30:06 -0500, "Keith P. Boruff" <kb*****@optonline.net> said:
Clark S. Cox III wrote:
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.


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.
--
Clark S. Cox, III
cl*******@gmail.com

Jul 23 '05 #45

P: n/a
Clark S. Cox III wrote:

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?


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.

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.


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

Jul 23 '05 #46

P: n/a
"Keith P. Boruff" wrote:

Clark S. Cox III wrote:
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.


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.

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 23 '05 #47

P: n/a
On Wed, 16 Feb 2005 23:33:27 +0100, Rolf Magnus
<ra******@t-online.de> wrote:
Chris Croughton wrote:
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.


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


Indeed...

Chris C
Jul 23 '05 #48

P: n/a
Chris Croughton wrote:

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.

Jul 23 '05 #49

P: n/a
Ron Natalie wrote:
Chris Croughton wrote:

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.


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.

Jul 23 '05 #50

51 Replies

This discussion thread is closed

Replies have been disabled for this discussion.