Description

seberg

opened on May 10, 2025

Issue body actions

Bug report

Bug description:

New Python versions give a DeprecationWarning for struct definitions that use _pack_ = True but do not specify the _layout_.

In a sense a new feature, but as I believe this is only relevant for bit-fields: wouldn't it make sense to allow leaving _layout_ unspecified when the struct contains no bitfields?
(I suppose that means giving it some default, such as the system native layout.)

The context is just seeing this in NumPy where bit-fields are not used so I was wondering: numpy/numpy#28926.
Adding the _layout_ isn't a problem of course, but if the no-bitfield case is common (not sure) it may be nice to not be forced to "decide" on an irrelevant _layout_ (or act up on the DeprecationWarning)?

Another question that comes to mind is that _layout_ = "native" or so seems potentially useful.

CPython versions tested on:

3.14

Operating systems tested on:

Other

Activity

1. seberg

   added

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on May 10, 2025
2. picnixz

   added

   topic-ctypes

   extension-modulesC modules in the Modules dirC modules in the Modules dir

   on May 10, 2025
3. picnixz commented on May 10, 2025

   

   picnixz

   on May 10, 2025

   Member

   More actions

   cc @encukou
4. encukou commented on May 12, 2025

   

   encukou

   on May 12, 2025

   Member

   More actions

   Well, the layout will be different wherever MSVC and GCC disagree.
   AFAIK, that's currently only the case with bitfields, but I haven't proven that, and can't guarantee it for any future features.

   We cannot add _layout_ = "native" because _pack_ not implemented for the GCC layout. With _layout_ = "native"; _pack_ = 1, you'd get an error on *nix.

   Historically, setting _pack_ has always implicitly switched to the MSVC layout. The attribute corresponds to MSVC's #pragma pack, not to some “platform-specific tight packing” that some readers might expect.
   IMO, it's in NumPy's interest to make this explicit -- by setting _layout_ = "ms".

   If the deprecation is a problem, I'd be OK with removing the warning altogether, and strenghtening _pack_'s documentation instead.

   (Those are just my current opinions -- feedback welcome!)
5. seberg commented on May 12, 2025

   

   seberg

   on May 12, 2025

   ContributorAuthor

   More actions

   I hope it was clear, I don't care too much about adding _layout_ = "ms" to NumPy, it's just a few tests. NumPy does pack, so tests that check that we pack the same and a few tests that you can read NumPy data via ctypes.

   Some user may use ctypes and be confused like me (why add _layout_ = "ms" when your code clearly works on all platforms?!). But I doubt it's common, so I really won't sweat it.

   The attribute corresponds to MSVC's #pragma pack, not to some “platform-specific tight packing” that some readers might expect.

   GCC also has __attribute__((packed)) (also for the full struct) for structs signaling that any variable is 1-byte aligned.
   So _pack_/_aligned_ is modeled after the MSVC pragmas, but I don't think it is conceptually specific to a toolchain (for byte-sized variables).

   AFAIK, that's currently only the case with bitfields, but I haven't proven that, and can't guarantee it for any future features.

   No need to proof anything. If _layout_ is unspecified, any possible future feature will just raise an error.
6. encukou commented on May 17, 2025

   

   encukou

   on May 17, 2025

   Member

   More actions

   If _layout_ is unspecified, any possible future feature will just raise an error.

   Well, here's the problem: the implementer of any future feature will need to remember to check whether it results in the same layout between GCC & MSVC.

   I'd be OK with entirely removing the warning (and eventual hard error) for _pack_ & no _layout_. But IMO, limiting it to just bitfields would become a maintenance burden.

   cc @BCSharp -- this thread might be interesting for you.

Issue actions