Removal of #include <HsFFI.h> from template-hsc.h breaks largefile support on 32bit Linux

[Simon Marlow]

On 17/02/2012 22:51, John Meacham wrote:
> On Fri, Feb 17, 2012 at 2:12 PM, Simon Marlow<marlowsd at gmail.com>  wrote:
>> On 17/02/12 19:36, John Meacham wrote:
>>>
>>> It isn't local to a file though because it changes the ABI, for instance
>>>
>>> void foo(off_t *x);
>>>
>>> it will blow up if called from a file with a differently sized off_t.
>>
>>
>> But we're talking about Haskell code here, not C code.  There's no way for
>> something to "blow up", the typechecker will catch any discrepancies.
>>
>> Perhaps I don't understand what problem you're thinking of - can you give
>> more detail?
>
> Someone writes a C function that returns an off_t * that is foreign
> imported by a haskell
> program using Ptr COff, the haskell program then writes to the output
> pointer with the COff
> Storable instance. However the imported function was compiled  without
> 64 bit off_t's so it
> only allocated 32 bits to be written into so some other memory gets
> overwritten with garbage.
> 64 bit off_t's change the ABI of called C functions
> much like passing -m32 or -mrtd does so should be considered a
> all-or-nothing sort of thing. In
> particular, when ghc compiles C code, it should make sure it does it
> with the same ABI flags
> as the rest of the thing being compiled.

So I'm not sure I agree with this.  If someone is writing some C code 
and some Haskell code that calls it, it is their responsibility to make 
sure they get it right.  Furthermore, GHC should not be imposing any 
choices on end users - what if you need to call an API that uses the 
32-bit off_t, for example?

We've had all kinds of trouble in the past with GHC's configuration 
details leaking into user's code, which is why we try to be as clean as 
possible now.  There are no ABI issues here - it's just a matter of the 
contract between the Haskell code and the C code, which is completely 
under the control of the user.

The only place where there the choices we make in GHC affect the user's 
code is the definition of the COff type.  We should make it clear in the 
documentation for COff which version of off_t it corresponds to (or 
maybe even have two versions), but IMO that's all we should do.

Cheers,
	Simon



>
>       John
> environment as the rest of the code.