Implement _layout_ on ctypes structs
#1937
Conversation
| private static LayoutKind GetStructLayout(PythonType type) { | ||
| if (type.TryGetBoundAttr(type.Context.SharedContext, type, "_layout_", out object layout) && layout is not null) { | ||
| if (Converter.TryConvertToString(layout, out string? layoutName)) { | ||
| if (layoutName.StartsWith("ms", StringComparison.Ordinal)) return LayoutKind.Msvc; |
There was a problem hiding this comment.
Any reason for using StartsWith instead of an exact check? The current 3.14 doc seems to say it should either be ms or gcc-sysv.
There was a problem hiding this comment.
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 was gcc- plus some OS name, but was it gcc-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 msvc for the MSVC layout, and for the GCC/Linux layout gcc, with aliases clang and gcc-sysv for the latter. Perhaps an alias ms for 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.
| 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: # bug in CPython | ||
| 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 ms when _pack_ is specified.
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 _layout_. The reason why IronPython diverges here from CPython is because CPython currently does not support #pragma pack with the GCC layout under any circumstances — at least not yet, and I do not see it on the roadmap. I read from the python/cpython#131747 (comment) by @encukou is that there are plans to overhaul the the whole _layout_ syntax to something more flexible and extensible, but it is at this point not fleshed out yet.
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 _layout_ = 'gcc-sysv', lest you be silently served the MSVC layout. So you would have to be explicit in Python to get the GCC default, and the default in Python is something rarely used in GCC... 😵💫
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 c_longlong (normally 64 bit), may require reading and processing 9 bytes. This can be done but will require a significant rework of the current code logic, and, frankly, I feel that I'd rather spend my effort on other things, hence no promises.
This is a new feature in 3.14, which is still in alpha, so I don't know if the string IDs identifying the layout will make to final intact. I find it a bit strange that for
msvcthey use the abbreviation of a company (ms) and forgccthey use the compiler name, hyphen, an operating system name.Therefore the tests to interpret the values of
_layout_are a bit relaxed than what CPython 3.14a6 allows. Once 3.14 is released, it will be easy to fix the actual string IDs to match CPython's.