Sigbjorn Am confused by your answer. | > 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.] So we don't need to worry about doing the masking on the Haskell side, right? | > 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. Why would we need these unless we *did* need to worry about masking on the Haskell side? Pls clarify. J