GHC FFI Return Type Bug

[Sigbjorn Finne]

"Julian Seward (Intl Vendor)" <v-julsew@microsoft.com> writes:
> 
> Hmm, we're looking at this.  However, I don't really know what
> C is or is not supposed to do here.  Given
> 
> char fooble ( ... )
> {
>    return 'z';
> }
> 
> on an x86, 'z' will be returned at the lowest 8 bits in %eax.
> What I don't know is, is the C compiler obliged to clear the
> upper 24 bits of %eax, or does that onus fall on the callee?

Yes, the callee is required to narrow <expr> in 'return <expr>;' to
fit that of the specified return type -- see 9.8 of Harbison and
Steele. So, a C compiler that cause f() to return 0x7fffffff for
the following,

unsigned char g()
{
    return 0x7fffffff;
}

unsigned int f()
{
    return g();
}

is in the wrong. [Notice that narrowing for signed integral types
is undefined in ISO C, but most current-day compilers implement
such narrowing ops the same way, i.e., by masking off excess bits.]

> Also, I don't even know where to look for the specification of
> details of the C calling conventions.  Anyone got a clue?
> 

Harbison & Steele Chapters 6 and 9 cover the conversion rules that
apply to functions (and other expressions). As you no doubt already
know, lower-level details are the domain of a platform's ABI.

Sounds to me like unboxed sized Words and Ints is the (unavoidable)
way to go.

--sigbjorn