Two bugs in unix64.S

[Dan Witte]

----- Original Message -----
> The main issue is that the ffi_call_unix64() function interprets its
> raddr argument differently than, say, ffi_call_win32() in win32.S. In
> ffi_call_win32() it is supposed to be a pointer to exactly as much
> memory as needed for the return type of the function, which I suppose
> is the intended semantics. However in ffi_call_unix64() we always
> writes 8 bytes into *raddr, even when the return type is declared as
> FFI_TYPE_SINT32 or FFI_TYPE_SINT8. The second, smaller, issue is that
> the assembler source code is missing "ret" at the end of the cases
> .Lst_uint16 and .Lst_uint32.

That's actually a bug in ffi_call_win32. It's a (apparently little-known) contract of the API that the return value pointer, for integral types, should be declared ffi_arg -- which is the size of the largest integral value.

ffi_call is supposed to sign- or zero-extend the return value into this size.

Patches accepted, I'm sure ;)

Regards,
Dan.