0

I found some C++ code that does something like this:

struct Test
{
    int a[128];
    char b[768];
};
 
int main()
{
    Test test;
    for( int i = 0; i < 200; ++i)
        test.a[i] = 1;
    return 0;
}

I realize it's wrong. But, I want to know what the effect will be? On GCC 4.3.4, the Test::b array is untouched. Is that guaranteed? What is happening here?

Is it the same effect for reading? e.g.

int main()
{
    Test test;
    for( int i = 0; i < 200; ++i)
        int z = test.a[i];
    return 0;
}
Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
PaulH
  • 7,759
  • 8
  • 66
  • 143
  • Numerous questions on this... e.g. http://stackoverflow.com/questions/10051782/array-overflow-why-does-this-work – djechlin Nov 29 '12 at 20:04
  • Voting to close as exact duplicate. If this really is regarded as different from other such questions then the only other opinion is too localized. – djechlin Nov 29 '12 at 20:05

5 Answers5

3

It's undefined behavior, and anything can happen.

There's much more variables to take into account than just the compiler - version, OS, hardware, weather, what day of the week it is, etc.

The standard says that undefined behavior can mean anything, so you can't really have any expectations, not even with the same compiler.

If, for example, you had a different variable located just after test.a, you could get an access violation. Or you could simply overwrite that variable. Anything goes.

Basically, it's not the writing part that undefined in this case, but the call to

test.a[i]

with i>=128. It's just not permitted.

Luchian Grigore
  • 253,575
  • 64
  • 457
  • 625
  • Is it _defined_ to be undefined behavior in the standard? I'm browsing it now, but not finding anything. – PaulH Nov 29 '12 at 20:08
1

It is undefined behaviour you cant predict what will be if you write outside bounds of array.

Denis Ermolin
  • 5,530
  • 6
  • 27
  • 44
0

Undefined behavior. There are absolutely no guarantees, and literally anything may happen. A common capricious remark is that it could e-mail goatse to your grandmother.

http://en.wikipedia.org/wiki/Undefined_behavior

In practice it will probably continue writing further into the Test object, although the beginning of b may not follow immediately after the end of a due to padding for alignment purposes.

http://en.wikipedia.org/wiki/Data_structure_alignment

Tyler McHenry
  • 74,820
  • 18
  • 121
  • 166
0

In C++, the abstract language defined by the C++ standard, anything at all can happen.

In G++ 4.3.4, the concrete language defined by this compiler, the specific anything that will happen is that you will overwrite the first 288 elements of test.b.

Robᵩ
  • 163,533
  • 20
  • 239
  • 308
0

Aside from the "undefined behavior", what really happens depends on whether the part you're overwriting is actually used or not. If that piece of memory isn't being used, it might cause an error or crash (depending if you're running anything to monitor the issue). However, if there is some data there and it does not crash, it might cause a cascade effect in your software where another piece of code that depends on the overwritten part fails to execute. This is what makes tracking these issues so hard, since when a cascade failure happens it's hard to find the root cause as opposed to the visible symptoms ("Why does this variable have a value x when I never ever assign that kind of value to it")

Gustavo Litovsky
  • 2,457
  • 1
  • 29
  • 41