[Lldb-commits] [PATCH] D18985: Fix test cases for big-endian systems

[Ulrich Weigand via lldb-commits]

uweigand added a comment.

In http://reviews.llvm.org/D18985#397674, @clayborg wrote:

> So many tests above are going to accept either a little endian or big endian value. This will make most of these tests useless since if a little endian machine fails with a big endian number we won't catch it and vice versa. So we need to expect the correct value for little endian and a different but correct one for big endian tests and only accept the correct one.


I fully agree this would be preferable.  Unfortunately I didn't see a straightforward way to detect in those test cases whether the target platform is big- or little-endian.  In the Python API tests this is simple, but these tests here just operate on the console interface.  Is there a good way to detect target byte order in such tests?

> Zero seems like a bad alternate value as it could cover up a real failure. Can we improve this test so that we are testing for actual values? Or can we change the test by endianness and test for 16777216 for little endian and something else that is not zero for big endian? We don't want zero to be valid for little endian tests.


The test case is a bit weird in how it (apparently deliberately) overlays mis-aligned synthetic fields across an integer array.  This is always going to behave quite differently depending on byte order.  I'll see if I can change the test so that values will be nonzero both on big- and on little-endian platforms.


http://reviews.llvm.org/D18985