Re: closure api return value types problem

[Andrew Haley <aph at redhat dot com>]

On 02/04/10 19:29, Sergei Trofimovich wrote:
> On Fri, 02 Apr 2010 09:40:31 +0100
> Andrew Haley <aph@redhat.com> wrote:
> 
>>> Just looked at cls_ushort.c(and other integrals) test:
>>>   *(ffi_arg*)resp = *(unsigned short *)args[0];
>>> and cls_float.c
>>>    *(float *)resp = *(float *)args[0];
>>>
>>> Integrals seem to strangely be casted to 'ffi_arg *'(long *) while FPU ones
>>> are casted to their real type. It's normal (but undocumented) or it's a
>>> horrible inconsistency bug?
>>
>> If you came up with a small self-contained test case it'd help a lot.
> 
> What kind of test you would like to see?
> The tests are in libffi tree and they all work correctly (even on ppc64):
> testsuite/libffi.call/cls_ushort.c
> testsuite/libffi.call/cls_float.c
> testsuite/libffi.call/cls_ulonglong.c

Right, so there is no problem, then.  I thought you said there was a
problem with ghc that you wanted to solve.

> But! The thing I don't understand is why libffi treats ushort, uint
> retval types (and _only_ retval types!) so specifically?

I think this is just because of the common (universal?) C ABI
convention that integer typed return values of rank less than int are
returned as a whole word, suitably sign- or zero-extended.  It need
not have been done that way.

Andrew.