CODEWITHSUNDEEP
c++pointersmemoryshared-memory
Galaxy
Galaxy

Reputation: 2481

Is it safe to change the dereference of an out-of-bounds pointer in C++?

Suppose I have a bad pointer that I increment to see what is inside the next memory locations. My code works fine without any errors or problems. I just print out the contents of these memory locations. I see the output on my screen, some of these memory locations have a value of 0, other ones contain some large negative or positive numbers that seem to be arranged in patterns. But what if I try to change or overwrite the contents of these memory locations? What do they represent? What kind of data may be stored in these memory locations, and is it possible to break the operating system if enough of these memory locations will be changed?

  #include <iostream>
  using std::cout;
  using std::endl;
  int main() {
    int num1 = 5;
    int* bad_ptr = &num1;
    cout << "Address of num1: " << &num1 << endl;
    cout << "Dereference bad pointer: " << *bad_ptr << endl;

    // The bad pointer acesses 500 memory addresses
    for (int i = 0; i < 500; i++) {
      bad_ptr++;
      cout << "Dereference bad pointer: " << *bad_ptr << endl;
      // What if I try to change it?
      // *bad_ptr = 1;
    }
    return 0;
  }

Upvotes: 1

Views: 152

Answers (2)

user3344003
user3344003

Reputation: 21647

Referencing a bad pointer is undefined. However, what you are doing is likely not to cause an error just by accident.

In most C++ implementations your num1 will be allocated on the stack. In most computer systems, stacks grow towards lower addresses. Your incrementing the pointer is moving yourself back up the stack into the stack frames of the calling functions (i.e., all those that do initialization before main).

If you make your loop limit large enough, eventually you will see a problem.

But what if I try to change or overwrite the contents of these memory locations? What do they represent? What kind of data may be stored in these memory locations, and is it possible to break the operating system if enough of these memory locations will be changed?

This is all system specific but, in general, when you call a function, you create a CALL FRAME on the stack. The call frame includes the arguments to the function, the address of the next instruction to execute after the function call returns, and saved registers.The call frame includes all the information needed to restore the calling function when the called function returns.

Usually there is a hardware register that points to the current call frame (a Frame Pointer).

In between call frames, the stack contains local variables for the currently executing function.

When a function returns, it uses the Frame Pointer register to locate the call frame. Then restores the data in the call frame (including the previously saved Frame Pointer value) and continues executing the calling function.

If you were to overwrite the contents of your pointer, that is what you must likely be mucking with. Your calling functions might see their variable change. Your program might crash. Anything can happen.

There are functions that muck with the call frame in the way you do. That requires knowing exactly how the call frames are laid out and the register usage.

For example, there is a common library function alloca() that is like malloc() except that it allocates memory on the stack so that it is automatically freed when current function returns. Implementing alloca requires messing with the state of the function that called it. That requires knowledge of the structure of the call frames.

And you are not going to break the operating system if you muck with these values. You are only going to hurt yourself.

Upvotes: 1

linuxuser27
linuxuser27

Reputation: 7353

TL;DR This is undefined behavior and should not be done.

The more practical answer is that it will very much depends on the address. In the example you are taking the address of an int that is on the stack. If you continue to increment the pointer, you are basically looking at stack memory. If you were to do the same thing with a pointer from a call to malloc() you would be looking at memory across the heap.

Your question about impacting the stability of the OS by changing values, unless you are in kernel space the answer is no. However, if you did this in a driver that was running in kernel space you could crash the OS.

This answer is definitely not exhaustive and is incredibly hand-wavy because there is a lot of nuance to your question, so I refer you to the TL;DR at the beginning. I would suggest searching and reading up on basic computer architecture.

Upvotes: 5

Related Questions