Can reading (not writing) a bad pointer cause the program to crash later ?

[jmnat]

Hello,

Let’s assume the following piece of code :

void f9 ()
{
char* c= "Could not execute f9";
throw c;
}

try
{
f9 ();
}
catch (char* c)
{
char message[4096];
sprintf (message, "Exception : %s", c);
cout << message;
}

This code works fine, its output is : "Exception : Could not execute f9".

Nevertheless, in the catch clause, the pointer c is indeterminate, the pointee may have been lost.

About such indeterminate (or “bad”) pointers, I have read the following :

If you are lucky, the dereference operation will crash or halt immediately (Java behaves this
way). If you are unlucky, the bad pointer dereference will corrupt a random area of
memory, slightly altering the operation of the program so that it goes wrong some
indefinite time later.
http://cslibrary.stanford.edu/102/PointersAndMemory.pdf

It seems I am unlucky, since my program has not crashed immediately.
But my question is : can it crash later because of this illicit dereferencing ?

In this case, I do not write in the area of memory pointed by by undeterminate pointer.
I only read it.

So, in such a case, can really the memory be corrupted so that my program may crash later ?

Thanks a lot for your ouputs

[newb16]

It is not lost as it's a constant string; It is not destroyed with f9 scope.
And yes, reading memory that doesn't belong to your program will cause program termination.

[jmnat]

thanks for your response, newb16, but in the catch clause of my program, we are no longer in f9 scope, so, there, it should be lost, isn't it ?

[Banfa]

Strictly speaking reading an indeterminate pointer location is undefined behaviour. That means anything can happen including the program running as expected and demons flying out of your nose. What actually happens may change for what appears to be a completely unrelated event on the system.

Undefined behaviour should be avoided at all costs.

as newb16 pointed out though you you are returning an indeterminate pointer, it is a pointer to a constant string. What you should be doing is throwing and catching const char * to reflect the constness of the string.

[jmnat]

@Banfa
Thanks for your response, Banfa

I know that undefined behavior should be avoided, no problem with that.

But can you give me some insight about how reading such an indeterminate pointer can cause the program to crash later (after the reading of the pointer) ?

Thanks in advance for your help

[jmnat]

@Banfa
Here is what one can read about that in the book "More Effective C++" :

char *p = "Hello"; // non-const pointer, // non-const data

const char *p = "Hello"; // non-const pointer, // const data

char * const p = "Hello"; // const pointer, // non-const data

const char * const p = "Hello"; // const pointer, // const data

https://www.lenep.uenf.br/~bueno/Dis...EC/EI21_FR.HTM

According to the °C++ standard, the type of "Hello" is const char [], a type that's almost always treated as const char*. We'd therefore expect it to be a violation of const correctness to initialize a char* variable with a string literal like "Hello". The practice is so common in C, however, that the standard grants a special dispensation for initializations like this. Nevertheless, you should try to avoid them, because they're deprecated. ¤
https://www.lenep.uenf.br/~bueno/Dis...EC/EI21_FR.HTM

Could you clarify (I am a bit lost) ?

Thanks again

[Banfa]

Yes, "Hello" is stored as part of the programs const data that is data used by the program that is known to be constant. This includes all string literals plus and any variables declared as const in the global scope.

However whether the const data is actually stored in physically unchangeable store or not is system dependent. For instance most PCs (MAC, Linux or Windows) store all data in RAM allocated from the system and so even the const data is stored in a memory location that is actually writeable, where as most embedded systems will store const data in the systems ROM (or more typically today EEPROM) so this data will be physically not writeable in the normal course of a program (of course will EEPROM you can always go the erase-rewrite route but that is not a simple assignment).

Because of that some C compilers for systems like PCs where everything is stored in RAM give "Hello" the type char * (or the systems char equivalent i.e. TCHAR * on Windows) where as others treat "Hello" as const char * even on systems where "Hello" is stored in RAM (for instance gcc I believe).

The only safe and portable thing to do is to treat string literals as constant, i.e. const char *.

However the C++ standard allows char *p = "Hello"; in order not to break the large body of C code out there that still assumes that string literals are not constant. But as your posted quite says that is deprecated behaviour, in new programs you should always treat string literals as const char *.

[Banfa]

@jmnat
I don't need to, once the program has invoked undefined behaviour it is in trouble. There is no need or point in trying to work out how it might be in trouble as this could vary from system to system and compiler to compiler.

[donbock]

I suggest the following construction for defining c:

static const char * const c = "Could not execute f9";

"static" makes pointer c persistent beyond the scope of f9; the two "const" may be overkill, but they help to make sure that the value of c and the contents of the string are stable.

[kanoop]

jmnat,

Reading the pointer cannot make the program crash in a delayed fashion. Seems that the discussion here was misdirected due to your example code which, depending on the compiler, may or may not show the issue you were wanting to illustrate.

Either the pointer will point at an address which is not mapped by the processor (or is mapped to a page that your program is not allowed to access), in which case a page fault will result and your program will crash immediately you dereference the pointer.

Or the pointer will point to an address which is mapped and you'll get away with it.

The text you quoted talks about 'bad pointer dereference', but the author has assumed (without clearly stating so) that the dereference is for a write operation - hence the confusion.