1

I was trying to understand the layout of an object by casting following two unrelated classes:

class A
{
public:
  A(int x):_a(x){}

private:
  int _a;
};

class B
{
public:
  void Show()
  {
    cout << "&_x = " << &_x << "," << " _x = " << _x << endl;
    cout << "&_y = " << &_y << "," << " _y = " << _y << endl;
    cout << "&_z = " << &_z << "," << " _z = " << _z << endl;
  }

private:
  int _x, _y, _z;
};

To test the classes the main has the following code:

int main()
{
  A * pA = new A(5);
  cout << pA << endl;
  B * pB = (B *) pA;
  pB->Show();
}

According to what I understand,

  • The call will succeed
  • B::_x will have value of A::_a
  • At run time, trying to access B::_y and B::_z in B::Show() should crash, as the object was originally of type A and of size 4 bytes, where as the compiler would expect _y and _z to be at offsets of 4 and 8 bytes from the starting address of the B object which is of size 12 bytes.

In realty though with VS2010, in debug mode, the statements in B::Show() are printed and _y and _z point to junk values, in release mode, the statements are printed, and _y and _z point to junk values, and then there is a crash (only sometimes :-().

I expected that we should have observed a crash as soon as we try to access _y and _z as they must be pointing to unallocated memory, but that doesn't happen. I know this is case is supposed to be under the realm of "undefined behavior", but still what is the possible explanation for this behavior?

Arun
  • 3,138
  • 4
  • 30
  • 41
  • There is no "should crash". The behavior is undefined. Anything can happen. – Pete Becker Aug 06 '13 at 11:33
  • You answered it yourself: undefined behavior means there are no guarantees - whatever assumptions you were making, they are wrong. There is no right assumption. – nikolas Aug 06 '13 at 11:34
  • 1
    Possible explanation: The memory used to allocate A came from a heap that's larger than the 4 bytes used by A. – Jonathan Potter Aug 06 '13 at 11:36

2 Answers2

0

The behaviour of undefined behaviour is undefined. By definition.

We can speculate about why the program fails in different ways, but the truth is it could change day-to-day, or run-to-run, or build-to-build.

Useless
  • 64,155
  • 6
  • 88
  • 132
0

This problem has no actual effect, forget it!

liangdong from baidu
  • 353
  • 4
  • 12