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