Overflowing char array overwrites the exact same string every time - why?

Question

I have the following code that shows the dangers of using char arrays over strings:

int main(){
    char password[] = "SECRET";
    char msg[10], ch;
    int i = 0;

    cout << "Please enter your name:";
    while((ch = getchar()) != '\n'){
            msg[i++] = ch;
    }
    msg[i] = '\0';

    cout << "\n\nHello " << msg << endl;
    cout << "The password is " << password;
}

When I enter a name (stored in char msg[10]) that is longer than 16 characters, everything after those 16 characters replaces the value stored in char password[] ("SECRET").

1. Why is this the case? (a general curiosity)
2. Why 16 characters and not 10 - the size of the array?
3. Why is it always password that gets overwritten and not some other variable or some other part of the memory where I wouldn't notice immediately?
4. What's the benefit of using char[] over strings then?

EDIT: Updated with follow up questions:
5. In response to the argument that password and msg are declared next to each other, I shuffled the declaration block as follows:

char password[] = "SECRET";
char ch;
int i = 0;
char msg[10];

However, no change.
6. In response to the argument that it was chance that caused the gap between msg and password to be 6 (bytes?) long, I have recompiled the code many times, including the reshuffling above. Still, no change.

Any suggestions as to why?

Answer 1

The answer for your first three questions is the same: because that's how your compiler chose to lay out these variables on the stack. Nothing in the standard guarantees that - in fact, what you're doing is undefined behavior - anything could happen.

Change compilers, or even compiler settings, and other things might happen. Or not. There's no telling.

As for 4, except for interoperability with C code, or other APIs that require C-style strings, essentially none.

Answer 2

Your two arrays msg and password are static, and therefore have been placed on the stack, meaning they're near each other.

The specifics are implementation dependent and are likely to change between compilers and optimisation levels. It's possible that the compiler has padded the stack a bit when allocating memory and there is a 16 byte gap between msg[0] and password[0].

password gets overwritten everytime because it just happens to be above msg on your stack. If you used a different compiler, or swapped their positions around in code, it might not be. How things are allocated on the stack isn't going to change between executions; it's determined at compile time (it's static), not runtime.

Note that, in principle, the compiler is free to do anything it wants! We can only make educated guesses about what'll happen given typical compiler behaviour. If you really want to know what's going on, you have to look at the ouput assembly.

std::string (for C++) is usually preferable to char[] - it's far safer as it implements bound checking and manages its own memory.

Answer 3

1 . In your case, memory is stored like that:

 msg                |   |i      |password
| | | | | | | | | | |1|2|3|4|5|6|S|E|C|R|E|T|\0

Then you write on msg progressively:

 msg                |           |password
|A|Z|E|R|T|Y|U|I|O|P|1|2|3|4|5|6|S|E|C|R|E|T|\0

But if you continue:

 msg                |           |password
|A|Z|E|R|T|Y|U|I|O|P|1|2|3|4|5|6|Q|W|E|R|T|Y|

Because char array doesn t check for length. (Search for overflow).

2 .You write on memory, you erase everything in between, maybe i or something that doesn t belong to your program.

3 .So it take 6 char before you overwrite password. It could have been 0char as well as millions.

4 .Unless you store a defined array of byte... Nothing, that is the point that code prove.

UPDATE:

1. Changing the place of code won t change padding, add variable, array, or better: use a different compiler, so that even after optimisation, the binary change.

2. Recompiling will not change the binary produced, because the compiler wil do the exact same thing.

Answer 4

1) writing outside an array will access something else.
2) alignment probably.
3) chance. anything can happen.
4) nothing!