Risk of damaging your computer by altering memory in C++

Question

I know some Java and am right now trying C++ instead and apparently in C++ you can do things like declare an int array of size 6, then change the 10th element of that array, which I'm understanding to be simply the 4th byte after the end of the section of memory that was allocated for the 6-integer array.

So my question is, if I'm careless is it possible to accidentally alter memory in my C++ program that is being used by other programs on my system? Is there an actual risk of seriously messing something up this way? I mean I know you can just restart your computer and clear the memory if you have to, but if I don't do that, there could be some lasting damage.

Answer 1

It depends on your system. Formally, an out of bounds access is undefined behavior. On a modern general purpose system, each user process has its own address space, and one process can't modify, or even read, that of another process (barring shared memory), so unless you're writing kernel code, you shouldn't be able to break anything outside of your own process (and non-kernel code can't normally do physical IO, so I don't see how anything in the hardware could break).

If you're writing kernel code, however, or working on an embedded processor with no memory mapping or protection, you can literally destroy hardware with an out of bounds write; if the program is controlling something like a nuclear power plant, you can even destroy a lot more than just the machine your code is running on.

Answer 2

Each process is given its own virtual address space, so naturally processes don't see each others memory. Don't forget that even a buffer overrun that is local to your program can have dire consequences - the overrun may cause the program to misbehave and do something that has lasting effect (like deleting all files for example).

Answer 3

This depends on what operating system and environment you are in:

• Normal OS (Windows, Linux etc) userspace program: You can only mess up your own process memory. However having really bad luck this can be enough. Imagine for example that you make a call to some function that deletes files. If your memory is corrupted at the time of the call, the parameters to the function might be messed up to mean deletion of something else than you intended. As long as you keep from calling delete file routines etc. in the programs where you test memory handling, this risk is non-existent.
• Normal OS, kernel space device driver: You can access system memory and the memory of the currently running process, possibly destroying everything.
• Simple embedded OS without memory protection: You can access everything and destroy anything.
• Legacey OS without memory protection (Win 3.X, MS-DOS): You can access everyting and destroy anything.