[GHC] #8650: Unexpected behaviour of import ccall "header.h function"
#8650: Unexpected behaviour of import ccall "header.h function" ------------------------------------+-------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- When I write {{{ foreign import ccall "myheader.h myfunction" function :: IO ... }}} Is GHC supposed to check the existence of the header file, or do anything with it? Because I can still write {{{"myheaderBLA.h myfunction"}}} and it doesn't care about the first word (no error, ever, not even in linking, executable builds all fine). ---- Relatedly, I can write {{{ foreign import ccall "some.rubbish" f :: IO ... }}} and as long as {{{"some.rubbish"}}} contains a dot, nothin in the system will ever complain. carter suggested that maybe names with a dot inside are ignored by a linker. This leads me to the question: In my example above, is {{{myheaderBLA.h}}} actually understood as some kind of file and ignored by e.g. GHC, or is it a garbled symbol name? In that case, why does http://www.haskell.org/onlinereport/haskell2010/haskellch8.html suggest {{{ccall "string.h strlen"}}}? In the other case, why would it suggest this if the {{{"string.h"}}} part is ignored? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8650 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8650: Unexpected behaviour of import ccall "header.h function" --------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by carter): so does ghc currently not check if the header file is visible among the enumerated include dirs when compiling the ffi binding? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8650#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8650: Unexpected behaviour of import ccall "header.h function" -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): From Section 8.5.1 of the report (emphasis mine):
The ''optional'' filename `chname` specifies a C header file, where the intended meaning is that the header file declares the C entity identified by `cid`.
C functions are normally declared using prototypes in a C header file. Earlier versions of GHC (6.8.3 and earlier) #included the header file in
GHC no longer includes external header files when compiling via C, so
From the GHC [https://www.haskell.org/ghc/docs/7.8.3/html/users_guide/ffi- ghc.html#glasgow-foreign-headers user's guide]: the C source file generated from the Haskell code, and the C compiler could therefore check that the C function being called via the FFI was being called at the right type. this checking is not performed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8650#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8650: Unexpected behaviour of import ccall "header.h function" -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): huh, so ghc no longer provides that validation because we no longer do f-via-c by default? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8650#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
In that case, why does http://www.haskell.org/onlinereport/haskell2010/haskellch8.html suggest {{{ccall "string.h strlen"}}}? In the other case, why would it suggest
#8650: Unexpected behaviour of import ccall "header.h function" -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: Basically, by providing the correct header file in the import specification, you gain portability to Haskell compilers which compile via C (including, but not limited to, ancient or unregisterised versions of GHC). Replying to [ticket:8650 nh2]: this if the {{{"string.h"}}} part is ignored? Because that is the Haskell 2010 Report, not the GHC documentation (though it would be accurate for unregisterised versions of GHC).
Relatedly, I can write
{{{ foreign import ccall "some.rubbish" f :: IO ... }}}
and as long as {{{"some.rubbish"}}} contains a dot, nothin in the system will ever complain.
As specified by section 8.5.1 of the Report, both the `chname` and the `cid` are optional. The Report does not specify how to resolve the resulting ambiguity, but since a C identifier cannot contain a dot, GHC must be treating `some.rubbish` as the header file name, and using the Haskell name `f` as the C identifier, as also specified by the Report:
If `cid` is omitted, it defaults to the name of the imported Haskell variable.
-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8650#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC