coding failures for cell on big endian
rmottola opened this issue · 5 comments
gui/GSCodingFlags/GSCellFlags.m:
Failed test: (2024-11-11 17:31:07.626 +0100) mask.flags translates to mask.value
Failed test: (2024-11-11 17:31:07.788 +0100) state is correctly set
Failed test: (2024-11-11 17:31:07.788 +0100) selectable is correctly set
Failed test: (2024-11-11 17:31:07.788 +0100) scrollable is correctly set
Failed test: (2024-11-11 17:31:07.788 +0100) continuous is correctly set
Failed test: (2024-11-11 17:31:07.788 +0100) truncateLastLine is correctly set
Verified on SPARC 64bit and PPC 32bit.
Could you please report the value of mask.value on these machines?
It is hard. If I run the test program in GDB, it segfaults!
I printed out octal:
Start set: GSCellFlags.m:13 ... GSCodingFlags GNUstep CellFlags Union
2024-11-12 22:02:09.974 GSCellFlags[1885:1076665840] GS_WORDS_BIGENDIAN = 1
Failed test: (2024-11-12 22:02:09.989 +0100) mask.flags translates to mask.value
Failed test: (2024-11-12 22:02:09.990 +0100) state is correctly set
Failed test: (2024-11-12 22:02:09.990 +0100) selectable is correctly set
Failed test: (2024-11-12 22:02:09.990 +0100) scrollable is correctly set
Passed test: (2024-11-12 22:02:09.991 +0100) editable is correctly set
Failed test: (2024-11-12 22:02:09.991 +0100) continuous is correctly set
Passed test: (2024-11-12 22:02:09.991 +0100) useUserKeyEquivalent is correctly set
Failed test: (2024-11-12 22:02:09.991 +0100) truncateLastLine is correctly set
End set: GSCellFlags.m:51 ... GSCodingFlags GNUstep CellFlags Union
printed out in octal 22016000110 is clearly not 0b00010010000000000001110000001001
instead that octal value is 10010000001110000000000001001000 which is the little endian?
Looks like we could just drop the endianness check here. Would be fine for me as long as it works. And it would prove that the way we handle endianness is actually working. The whole idea here is that we interpret the bit values correctly independently of the processor endianness.
So the test is wrong? Makes sense