[Hackage] #190: extension ForeignFunctionInterface should imply -fvia-C for ghc
#190: extension ForeignFunctionInterface should imply -fvia-C for ghc --------------------------+------------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.1 Platform: Linux | --------------------------+------------------------------------------------- I think the recommended practice with ghc is for code that uses FFI to compile via C to get the benefit of checking against C headers. So using that extension should imply not just -fffi but -fvia-C for ghc. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/190 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#190: extension ForeignFunctionInterface should imply -fvia-C for ghc --------------------------+------------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.1 | Platform: Linux --------------------------+------------------------------------------------- Comment (by guest): Note that `-fvia-C` can hide some problems, as well as exposing others, in a library. Typically you should test with both. The main problem is that `-fvia-C` sees definitions from header files, so if an identifier has been `#defined` to something else, then `-fvia-C` will see it, but `-fasm` won't. A good example is the A-vs-W functions on Windows: `OpenFile` is `#define`d to `OpenFileA` or `OpenFileW` depending on whether unicode support is enabled. The FFI declaration should use `OpenFileW` directly, so that it works with `-fasm`. Also, if you get the calling convention wrong on Windows (e.g. `ccall` instead of `stdcall`), then `-fvia-C` will hide the error, because it will see the C prototype with the correct calling convention annotation. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/190#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#190: extension ForeignFunctionInterface should imply -fvia-C for ghc --------------------------+------------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.1 | Platform: Linux --------------------------+------------------------------------------------- Comment (by guest): That's a big switch to flip just because someone wants to use the FFI; it has the potential to trigger all sorts of GHC bugs. Also, remember that `-fvia-C` is heading towards being deprecated. Ian -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/190#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#190: extension ForeignFunctionInterface should imply -fvia-C for ghc --------------------------+------------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.1 | Platform: Linux --------------------------+------------------------------------------------- Comment (by duncan): So what is the recommendation from GHC HQ these days? From the [http://haskell.org/ghc/docs/6.8.2/html/users_guide/ffi-ghc.html #glasgow-foreign-headers GHC user guide:] Note that this approach is only ''essential'' for returning floats (or if sizeof(int) != sizeof(int *) on your architecture) but is a Good Thing for anyone who cares about writing solid code. You're crazy not to do it. Has that recommendation changed? Perhaps we don't want to always use -fvia-C if we're doing FFI for the reasons mentioned above, but what should the default be? Sounds like it should still be -fvia-C and not -fasm. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/190#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#190: extension ForeignFunctionInterface should imply -fvia-C for ghc --------------------------+------------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.1 | Platform: Linux --------------------------+------------------------------------------------- Comment (by guest): My reading of that is "If you are using FFI via C, write a header file", not "If you are using the FFI, go via C". I can't see why GHC shouldn't be able to do the right thing (according to your Haskell type signature, at least) when generating the code itself. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/190#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#190: extension ForeignFunctionInterface should imply -fvia-C for ghc ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: wontfix Keywords: | Difficulty: normal Ghcversion: 6.8.1 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => wontfix Comment: We've decided to leave the defaults as they are. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/190#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
participants (1)
-
Hackage