NULL pointer dereferencing - behaviour

B

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?
 
B

BigMan

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?
 
V

Victor Bazarov

BigMan said:
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
 
A

Andrea Sini

BigMan said:
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
 
C

Chris Croughton

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
 
A

ajitho

#include <stdio.h>

class MyClass {
public:
void A() {
if (this==NULL) printf("NULL Pointer\n");
}
};


void main() {
MyClass *ptr = 0;
ptr->A();
}
 
V

Victor Bazarov

Chris said:
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
 
V

Victor Bazarov

ajitho said:
#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
 
A

ajitho

#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);
}
 
V

Victor Bazarov

ajitho said:
#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.
 
A

Andrey Tarasevich

ajitho said:

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

Andrey Tarasevich

ajitho said:

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

ajitho

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

Pete Becker

ajitho said:
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.
 
N

Noah Roberts

Pete said:
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.
 
A

ajitho

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

Chris Croughton

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top