closure: fix handling of ENUMs and integral return types on 64-bit BE platforms
authorDan Williams <dcbw@redhat.com>
Fri, 23 Sep 2011 17:32:23 +0000 (12:32 -0500)
committerDan Williams <dcbw@redhat.com>
Wed, 5 Oct 2011 19:08:22 +0000 (14:08 -0500)
commit8e82225aedf81ea8a33deb3eb27a8878cd606521
tree052e2e42396c73997191e884f74a33bf290cadf4
parentc3133affcd55023a5e9cfbd87ec96e04a13c8e86
closure: fix handling of ENUMs and integral return types on 64-bit BE platforms

enums are stored in v_long but need to be marshalled as signed
integers.  On platforms where int is 32 bits, taking the
address of v_long resulted in the wrong 32 bits being marshalled.
So we need to stuff the enum's int-sized value to a temporary
int-sized variable and marshall that instead.

Second, on return, libffi actually returns a pointer to a value
that's sized according to platform conventions, not according to
what the caller requested.  ie if ffi_type_sint was requested, the
value can still be a 64-bit sign-extended long on a 64-bit
architecture like PPC64, thus the caller cannot simply cast
the return value as a pointer to the desired type, but must cast
as a pointer to an integral type and then cast to the desired
type to remove any sign extension complications.

For more information on how to correctly handle libffi return
values, see the following bug, specifically comment 35:

https://bugzilla.redhat.com/show_bug.cgi?id=736489

"For 64-bit ABIs that extend integral returns types to 64-bits, libffi always
returns full 64-bit values that you can truncate in the calling code.   It's
just the way it is has always been.  Please don't change libffi.  I'll document
this clearly for the next version (perhaps there is a mention of this, I
haven't looked yet).

The same is true for returning 8-bit values, for instance, on 32-bit systems.
All ABIs extend those results to the full 32-bits so you need to provide a
properly aligned buffer that's big enough to hold the result."

https://bugzilla.gnome.org/show_bug.cgi?id=659881
gobject/gclosure.c