Implement _layout_ on ctypes structs
#1937
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -507,12 +507,12 @@ class Test(Structure): | |
| ] | ||
|
|
||
| self.check_bitfield(Test.a, c_longlong, 0, 0, 20) | ||
| if is_posix and (is_cli or sys.version_info < (3, 14)): # CPython 3.14 implements MSVC behaviour when _layout_ is not set | ||
| if is_cli: # GCC-compliant results | ||
| self.check_bitfield(Test.b, c_short, 2, 4, 2) | ||
| self.check_bitfield(Test.c, c_short, 2, 6, 15) | ||
| self.assertEqual(sizeof(Test), 5) | ||
| else: # https://github.com/python/cpython/issues/131747 | ||
|
There was a problem hiding this comment. Just a quick note on your CPython bug report, the current dev doc does say that it defaults to There was a problem hiding this comment. Yes, so it is a "documented bug" as I see it, and technically python/cpython#131747 is probably a feature request, one that was not practical before 3.14 started to support OTOH for IronPython, as the next steps, I intended to implement the GCC layout for bitfields in a GCC-compliant way. Following CPython's documented behaviour literally would mean that to get the default GCC behaviour with bitfields on Linux you would have to set Just to be clear, this PR does not bring GCC packed layout with bitfields yet — it's just the tests, which are currently being skipped. Implementing GCC packing with bitfields turned out to be surprisingly cumbersome, as GCC can lay the fields out in such a way that to access them requires more data than the total size of the underlying data type used. E.g. as I currently understand it, to access a bitfield of length 57 defined on |
||
| self.check_bitfield(Test.b, c_short, 6, 20, 2) | ||
| self.check_bitfield(Test.c, c_short, 6, 22, 15) | ||
| self.assertEqual(sizeof(Test), 8) | ||
|
|
@@ -905,6 +905,55 @@ class Test(Structure): | |
| self.assertEqual(sizeof(Test), 16) | ||
|
|
||
|
|
||
| @unittest.skipUnless(is_cli or sys.version_info >= (3, 14), '_layout_ not supported before CPython 3.14') | ||
| def test_bitfield_mixed_H3_layout_msvc(self): | ||
| class Test(Structure): | ||
| _layout_ = 'ms' | ||
| _fields_ = [ | ||
| ("a", c_longlong, 52), | ||
| ("b", c_byte, 5), | ||
| ] | ||
|
|
||
| self.check_bitfield(Test.a, c_longlong, 0, 0, 52) | ||
| self.check_bitfield(Test.b, c_byte, 8, 0, 5) | ||
| self.assertEqual(sizeof(Test), 16) | ||
|
|
||
|
|
||
| @unittest.skipUnless(is_cli or sys.version_info >= (3, 14), '_layout_ not supported before CPython 3.14') | ||
| def test_bitfield_mixed_H3_layout_gcc(self): | ||
| class Test(Structure): | ||
| _layout_ = 'gcc-sysv' | ||
| _fields_ = [ | ||
| ("a", c_longlong, 52), | ||
| ("b", c_byte, 5), | ||
| ] | ||
|
|
||
| self.check_bitfield(Test.a, c_longlong, 0, 0, 52) | ||
| self.check_bitfield(Test.b, c_byte, 7, 0, 5) | ||
| self.assertEqual(sizeof(Test), 8) | ||
|
|
||
|
|
||
| @unittest.skipUnless(is_cli or sys.version_info >= (3, 14), '_layout_ not supported before CPython 3.14') | ||
| def test_bitfield_mixed_H3_layout_default(self): | ||
| class Test(Structure): | ||
| _layout_ = None | ||
| _fields_ = [ | ||
| ("a", c_longlong, 52), | ||
| ("b", c_byte, 5), | ||
| ] | ||
| self.assertEqual(sizeof(Test), 8 if is_posix else 16) | ||
|
|
||
|
|
||
| @unittest.skipUnless(is_cli or sys.version_info >= (3, 14), '_layout_ not supported before CPython 3.14') | ||
| def test_bitfield_mixed_H3_layout_invalid(self): | ||
| with self.assertRaises(ValueError) as context: | ||
| class Test(Structure): | ||
| _layout_ = "invalid" | ||
| _fields_ = [] | ||
|
|
||
| self.assertIn("unknown _layout_", str(context.exception)) | ||
|
|
||
|
|
||
| @unittest.skipIf(is_posix, 'Windows specific test') | ||
| def test_loadlibrary_error(self): | ||
| with self.assertRaises(OSError) as cm: | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason for using
StartsWithinstead of an exact check? The current 3.14 doc seems to say it should either bemsorgcc-sysv.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My reason was that 3.14 is still in alpha and I find the current choice somewhat unfortunate, so I wouldn't be surprised if it changes before the release. In all places I've seen the layouts are called the MSVC layout and the GCC layout (sometimes GCC/Clang layout). Additionally, in the first few weeks working on layout I kept forgetting the string
gcc-sysv. I remembered that it wasgcc-plus some OS name, but was itgcc-aix?gcc-hpux? etc... I bet that in a year I'll forget again... 👴I think I can guess why the names were chosen as they are, but it does not convince me these were the best choices. If it were up to me, I would use
msvcfor the MSVC layout, and for the GCC/Linux layoutgcc, with aliasesclangandgcc-sysvfor the latter. Perhaps an aliasmsfor the former, if you insist.I don't know the CPython's development process, perhaps there is some sort of a review of new features before the beta is released, so maybe the names will be changed. I suppose once 3.14b1 is released, the names will be baked in for good. The more relaxed check is in place in case I don't have time (or forget) to come back and fix it in IronPython to whatever the beta will have.