GHC FFI Return Type Bug

[Julian Seward (Intl Vendor)]

Sigbjorn

Am confused by your answer.

| > char fooble ( ... )
| > {
| >    return 'z';
| > }
| >=20
| > 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=20
| > %eax, or does that onus fall on the callee?
|=20
| Yes, the callee is required to narrow <expr> in 'return=20
| <expr>;' to fit that of the specified return type -- see 9.8=20
| of Harbison and Steele. So, a C compiler that cause f() to=20
| return 0x7fffffff for the following,
|=20
| unsigned char g()
| {
|     return 0x7fffffff;
| }
|=20
| unsigned int f()
| {
|     return g();
| }
|=20
| is in the wrong. [Notice that narrowing for signed integral=20
| types is undefined in ISO C, but most current-day compilers=20
| implement such narrowing ops the same way, i.e., by masking=20
| off excess bits.]

So we don't need to worry about doing the masking on the=20
Haskell side, right?

| > Also, I don't even know where to look for the specification=20
| of details=20
| > of the C calling conventions.  Anyone got a clue?
| >=20
|=20
| Harbison & Steele Chapters 6 and 9 cover the conversion rules=20
| that apply to functions (and other expressions). As you no=20
| doubt already know, lower-level details are the domain of a=20
| platform's ABI.
|=20
| Sounds to me like unboxed sized Words and Ints is the=20
| (unavoidable) way to go.

Why would we need these unless we *did* need to worry about
masking on the Haskell side?

Pls clarify.

J