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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
