closure api return value types problem

[Timothy Wall]

On May 19, 2010, at 5:33 PM, Mat Hostetter wrote:

>>> * I think you meant 'less than word' here (ppc64 has 64bit word and 32bit int),
>>>   otherwise libffi has even stranger architecture specific assumptions and we
>>>   need more fixes.
> 
>> Yes, I did mean "less than word".
> 
> I'm porting libffi to a new 64-bit platform, and I'm confused about
> exactly how my 'ffi_call' is supposed to fill in subword return values.
> 
> The return_sc.c test does this:
> 
>  ffi_arg rint;
> ...
>  args[0] = &ffi_type_schar;
> ...
>      ffi_call(&cif, FFI_FN(return_sc), &rint, values);
>      assert(rint == (ffi_arg) sc);
> 
> which implies that an ffi_call returning a signed char must actually
> fill in by reference a full ffi_arg worth of bits, properly sign
> extended.  Since that's supposed to be the register size, that would
> require a 64-bit store.  OK, I can do that.
> 
> But if you look at the example that ships in the libffi info pages, it
> does this:
> 
>       int rc;
> ...
>       if (ffi_prep_cif(&cif, FFI_DEFAULT_ABI, 1,
>                       &ffi_type_uint, args) == FFI_OK)
> ...
>           ffi_call(&cif, puts, &rc, values);
> 
> Note how the return value here is only 32 bits (int). So if my
> ffi_call stores 64 bits (ffi_arg), as required to make the test suite
> happy, it will overrun the stack in the simple example in the info pages.
> 
> Is the example wrong?
> 

The example is wrong, and should use type ffi_arg rather than "int".


> -Mat