Re: does it matter how I construct an aggregate struct type if its size is the same?

[Hayden Livingston <halivingston at gmail dot com>]

Thanks for this, Andrew. I've now read up a bit more and can safely
say that I agree with you AND understand it.

Also realizing that intricacies of compiler differences and ABI issues
that people often prefer to keep their public APIs are pointer size or
less.

On Fri, Dec 18, 2015 at 2:24 PM, Andrew Haley <aph@redhat.com> wrote:
> On 18/12/15 22:15, Hayden Livingston wrote:
>> Sorry, I should have been clearer -- I'm absolutely talking about
>> passing by value. But isn't it on a per argument basis and on its
>> size? If you have a data structure that is 9 bytes, after alignment
>> let's say it's 12, isn't that all that matters?
>
> No.
>
>> I mean I'm new to this but it seems that if you have a function
>> compiled by compiler 1, and let's say it is "exported", i.e. some body
>> else can call into this code via dlopen/loadlibrary you can't
>> arbitrarily decide how things should be passed right? It has to be on
>> an ABI-level, and the ABI I'm guessing says parameter 1 if it's size <
>> X can be passed on the stack, or use some registers, but does an ABI
>> also specify that struct member 1 if is less than X size can be passed
>> in register?
>
> Yes, it often does exactly that.  So if you have an arg which is 2
> ints then the 2 ints get passed in 2 registers.  Float members get
> passed in float registers, etc.  These days that's the way things are
> usually done, with some exceptions such as legacy 32-bit x86.
>
> The ABI really does need to know what is inside the struct.
>
>> This would mean you have to use only 1 compiler.
>
> Huh?  Its the ABI.
>
>> While typing this email, a thought occurred to me that probably we
>> programmers know this, and therefore never make our public
>> dlopen/loadlibrary APIs take structs that are not completely opaque?
>>
>> Sorry I'm formulating some of my thoughts .. but I'm new to this.
>
> Fair enough.
>
> Andrew.