[issue16733] Solaris ctypes_test failures
Greg Onufer <gonu...@jazzhaiku.com> added the comment: Or probably just change the type of the bitfield from "int" to "signed int"! -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue16733> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16733] Solaris ctypes_test failures
Greg Onufer <gonu...@jazzhaiku.com> added the comment: The bitfields failures are due to Python not implementing bitfields the same as the compiler. https://docs.oracle.com/cd/E77782_01/html/E77792/gqexw.html "Signed and Unsigned int Bit-fields Bit-fields which are declared as int (not signed int or unsigned int) can be implemented by the compiler using either signed or unsigned types. This makes a difference when extracting a value and deciding whether to sign extend it. The Oracle Developer Studio compiler uses unsigned types for int bit-fields and the gcc compiler uses signed types. Use the gcc –funsigned-bitfields flag to control this behavior. For more information, see the sixth list item at https://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Non_002dbugs.html.; When the test compares the ctypes extraction of the bitfield (signed) and the compiler-native extraction of the bitfield (unsigned), they miscompare if the high-bit of the field is set. If Python wants bitfields extracted from signed integral types to be signed, the C code in the test case needs to account for the compiler implementation defined behavior and sign extend the bitfield before returning it. See patch in attachment. The bitfield tests pass with those changes. -- keywords: +patch nosy: +gco Added file: https://bugs.python.org/file47580/0001-Fix-ctypes-bitfield-test-code-to-account-for-compile.patch ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue16733> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28055] pyhash's siphash24 assumes alignment of the data pointer
Greg Onufer added the comment: 32-bit and 64-bit SPARC ABIs have 64-bit integer data types. SPARC, like many RISC architectures, also has natural alignment requirements. Attempting to dereference a pointer to a 4-byte-sized object requires 4-byte alignment, for example. 2-byte-sized objects require 2-byte alignment. 8-byte-sized objects require 8-byte alignment. siphash24 is encountering this bug on modern SPARC (32-bit ABI currently, haven't tried compiling as 64-bit yet). The code simply is not portable. Benjamin's patch gets the failing self-test (test_plistlib) to pass as well as the simple test case in msg275493 above. -- nosy: +gco ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
