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

On 17/02/2012 22:51, John Meacham wrote:

On Fri, Feb 17, 2012 at 2:12 PM, Simon Marlow 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.