Opened 3 months ago

Last modified 3 months ago

#8650 new bug

Unexpected behaviour of import ccall "header.h function"

Reported by: nh2 Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.6.3
Keywords: Cc: mail@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Documentation bug Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

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?

Change History (1)

comment:1 Changed 3 months ago by carter

so does ghc currently not check if the header file is visible among the enumerated include dirs when compiling the ffi binding?

Note: See TracTickets for help on using tickets.