oop: corruption bugfix.

* struct.c (alloc_seen): Fix under-sized alloca and memset,
where the size being used is the number of elements,
but should be the number of bytes. This showed up as a
failure in the tests/012/oop-mi.tl on PPC64, uncovered by
a completely unrelated change in eval.c. The unrelated code
never executes during the failed test case; it just affects
some memory contents of the stack somehow. The under-allocated
array is used during structure type initialization to hold
a bitmask which helps to suppress the duplicate initiation of
base structures which are inherited multiple times (duplicate
bases).  I think why this shows up on PPC64 is the big endian
order. The sizes involved are small. The test case has a couple
of duplicate bases only, but a full 64 bit mask needs to be
allocated for that since the mask is an array of ucnum. On
little endian, it doesn't matter than only a single byte is
allocated: that is enough for 8 duplicate bases, and because of
the byte order, those bases land into the byte that is allocated.
On big endian, the bases will be on the high part of the 64
bit word, and thus over in the area we didn't allocate.
To reproduce an issue on little endian, you need an inheritance
hierarchy with more duplicate bases.

0 files changed, 0 insertions, 0 deletions