bad pointer exception

[Chris]

Hello.

how do you catch bad pointer dereferences in C++?

example:

#include <stdio.h>
void main()
{
try
{
int *pi;
*pi = 10;
}
catch(...)
{
printf("Exception caught \n\n");
}
}

catch handler is not executed, I get a runtime error instead.

so how?

thx
Chris

 

[Victor Bazarov]

how do you catch bad pointer dereferences in C++?

There is no standard way. Some systems have their special ways, though,
like on Windows you could try catching the "Access Violation" exception...

example:

#include<stdio.h>
void main()

int main()

{
try
{
int *pi;
*pi = 10;

This is undefined behaviour, and not necessarily a "bad pointer
dereference". What if *by chance* the pointer contains the address of a
normal, valid integer object? No guaranteed behavior here.

}
catch(...)
{
printf("Exception caught \n\n");
}
}

catch handler is not executed, I get a runtime error instead.

so how?

RTFM for your platform to see what to do about the runtime errors.

V

 

[Paul Bibbings]

Hello.

how do you catch bad pointer dereferences in C++?

example:

#include <stdio.h>
void main()
{
try
{
int *pi;
*pi = 10;
}
catch(...)
{
printf("Exception caught \n\n");
}
}

catch handler is not executed, I get a runtime error instead.

If your compiler is able to compile the above code and does not choke on
void main(), then it can probably achieve anything.

For a conforming implementation, however, you should enable an
appropriate warning level and expect/hope that the compiler will pick up
such coding errors. For instance:

19:13:04 Paul Bibbings@JIJOU
/cygdrive/D/CPPProjects/CLCPP $cat catch_error.cpp
#include <cstdio> // prefer over <stdio.h>

int main()
{
try
{
int *pi;
*pi = 10;
}
catch(...)
{
printf("Exception caught\n");
}
}

19:13:12 Paul Bibbings@JIJOU
/cygdrive/D/CPPProjects/CLCPP $i686-pc-cygwin-gcc-4.4.3 -ansi
-pedantic -Wall -c catch_error.cpp
catch_error.cpp: In function ¡®int main()¡¯:
catch_error.cpp:9: warning: ¡®pi¡¯ is used uninitialized in this
function

If you leave until runtime then dereferencing pi might or might not
produce a runtime error, depending on what address the junk value of pi
contains.

In short, don't allow such an oversight to remain in executing code, and
get your compiler to help you.

Regards

Paul Bibbings

 

[Goran]

Hello.

how do you catch bad pointer dereferences in C++?

"catch"? There's no such thing. And I mean, __AT ALL__.

What you can do with MS compiler (so we are off topic here) is catch
accesses to memory addresses that are in the address space of your
process, but you have no access to them (reasons vary). But that is
only due to IMNSHO massive blunder of MS when they allowed "structured
exceptions" to be caught by catch(...). BTW, they halfheartedly went
back on that decision, but as usual with MS, once mistake is made, it
lingers forever for backwards compatibility reasons.

Also... Although it seems so, your question has nothing to do with C+
+, but C. There's absolutely nothing in C++ specific to handling bad
pointer access. As said, it's equally undefined behavior in both
languages.

Goran.

 

[Chris]

Dereferencing a bad pointer results in undefined behaviour - it doesn't
throw, so you can't catch it. You just have to make sure you don't mess
up If you use smart pointers (e.g. shared_ptr) instead of raw
pointers, they are sometimes checked on use (against NULL only and
generally in debug mode only), but that's about as much help as you're
likely to get. Other than that, you're pretty much on your own...

Cheers,
Stu

p.s.

1) int main()
2) #include <cstdio>
3) (Add #include <iostream> and then...) std::cout << "Exception
caught\n\n";

"Dereferencing a bad pointer results in undefined behaviour".

How can it be undefined behaviour if it generates a runtime error time
and time again?
Doesn't it just mean that, when trying to access memory that isn't
yours it should be considered as 'Access violation' ?

Is there absolutely no way to prevent the program from crashing?

grtz

 

[Victor Bazarov]

"Dereferencing a bad pointer results in undefined behaviour".

How can it be undefined behaviour if it generates a runtime error time
and time again?

The definition of "undefined behaviour" is that the behaviour of the
code is not defined by the C++ language standard. Did you know we have
a standard for the language? Anyway, the Standard imposes no
requirements on the code that dereferences an uninitialized pointer.
Generating a run-time error falls under that definition - nothing in
particular is required to happen. IOW, *anything* may happen for all we
care. And it's going to be OK according to the Standard.

It's not "_random_ behaviour". It's *undefined*.

Doesn't it just mean that, when trying to access memory that isn't
yours it should be considered as 'Access violation' ?

Is there absolutely no way to prevent the program from crashing?

Please use the F1 key and read about access violations and how to deal
with them.

V

 

[Goran]

"Dereferencing a bad pointer results in undefined behaviour".

How can it be undefined behaviour if it generates a runtime error time
and time again?

It does, or it does not. It depens on the situation. In your code, on
your system (or your "class" of systems), compiled with your (version
of the) compiler, it generates "runtime error". It can be __completely
different__ somewhere else.

Here's why (but we are stepping completely out of the land of anything
guaranteed by C and C++ languages)...

When you write int* pi in a function, pi is placed on the stack of
your main. It is not initialized (because you didn't do it), and hence
has value of whatever was in memory. And that means __whatever__. Any
integral value size of a pointer is possible. So your pi points to any
memory location possible. It may point to memory that belongs to your
code, or that does not belong to it. There is __no guarantee
whatsoever__. Hence the undefined behavior.

I have to press you here: you must understand C language better first.
Forget C++ and exceptions. Understand handling memory in C. Understand
what does it mean "undefined behavior". Once you do that, answer to
your question will be evident (and will pretty much be what people
here are telling you).

Goran.