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?
Cheers,
Simon
John
On Fri, Feb 17, 2012 at 4:23 AM, Simon Marlow<marlo...@gmail.com> wrote:
On 16/02/2012 13:25, Eugene Crosser wrote:
Hello Simon, thanks for your attention :)
On 02/16/2012 04:25 PM, Simon Marlow wrote:
I found that earlier versions of hsc2hs included HsFFI.h into the
[...]
As I understand, this situation means that while the ghc itself and
haskell programs compiled by it are largefile-capable, any third party
modules that contain .hsc files are not. If I am right, this is probably
not a good thing.
We discovered this during the 7.4 cycle:
http://hackage.haskell.org/trac/ghc/ticket/2897#comment:12
Packages that were relying on `HsFFI.h` to define `_FILE_OFFSET_BITS`
should no longer do this, instead they should use an appropriate
autoconf script or some other method. See the `unix` package for an
example of how to do this. It was really a mistake that it worked
before.
But that means that the "C build environment" has to be constructed
independently for each module (that needs it), and consequently is not
guaranteed to match the compiler's environment. Would it be better (more
consistent) to propagate GHC's (or other compiler's) environment by
default, along the lines of the comment #16? To cite Duncan, "each
Haskell implementation has its own C environment, and hsc2hs must use
that same environment or it will produce incorrect results."
Just a thought, and, as I said, I am not really qualified to argue...
Well, the question of whether to use 64-bit file offsets or not really has
nothing to do with GHC itself. The choice is made in the base package and
is only visible via the definition of Foreign.C.Types.COff and through the
unix package. In fact, there's nothing stopping your own package from using
32-bit file offsets if you want to.
The time you would want to be compatible is if you want to make your own FFI
declarations that use Foreign.C.Types.COff. In that case you need to know
that the base package is using _FILE_OFFSET_BITS=64 and do the same thing.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
