[Python-ideas] improving C structs layout

[Andrew Barnert]

On May 8, 2013, at 9:59, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Wed, 8 May 2013 09:17:27 -0700
> Andrew Barnert <abarnert at yahoo.com> wrote:
> 
>> On May 8, 2013, at 6:52, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> 
>>> On Wed, 08 May 2013 15:45:09 +0200
>>> Alfredo Solano <asolano at icai.es> wrote:
>>>> Hi,
>>>> 
>>>> Interesting observation, but isn't C struct alignment platform/compiler
>>>> dependent?
>>> 
>>> The ABIs are standardized, so I would answer no.
>> 
>> What standard are you talking about? There's certainly no ABI standard that covers both Win64 and ARM7 Linux.
> 
> Per-platform ABI standards. Compilers aren't generally free to invent
> things if they want to be interoperable with each other.

That's my point. You said it wasn't platform dependent, and that's clearly not true. And python runs on multiple platforms. So Unless you want to have different layouts for each platform, there is no standard.

>>> Even if they weren't, there are common sense rules to minimize padding,
>>> such as to put fields of the same width next to each other (e.g. put
>>> chars together instead of intermingling them with ints and floats).
>> 
>> This is true... But you have to keep in mind that the width of different types is itself platform-dependent. If you've got an int, a long, a pointer, and a double, how do you pack them in a way that makes sense for all platforms, or even just the big 3 of x86_64 Mac/Linux/BSD, Win64, and Win32?
> 
> Well, you can be sure that int <= long, and in most cases you can assume
> other inequalities such as int <= pointer and int <= double (and even
> pointer <= double). The long <=> pointer relationship is less
> predictable, but on common platforms long <= pointer.
> 
> So, double then pointer then long then int.

On a platform with 64-bit long and 32-bit pointer, this would leave a gap.

Fortunately, even though this is perfectly legal, no major platform has these sizes.

And that's exactly why you have to prioritize for the most important platforms, instead of only pretending that standards make that unnecessary.

I think you were already implicitly doing that, but you were explicitly claiming not to.