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:


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 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.