- FFI - Haskell.org

Foreign.StablePtr: nullPtr & double-free questions.
by Remi Turk 14 Mar '13

14 Mar '13

Good night everyone, I have two questions with regards to some details of the Foreign.StablePtr module. [1] 1) The documentation suggests, but does not explicitly state, that castStablePtrToPtr `liftM` newStablePtr x will never yield a nullPtr. Is this guaranteed to be the case or not? It would conveniently allow me to store a Maybe "for free", using nullPtr for Nothing, but I am hesitant about relying on something that isn't actually guaranteed by the documentation. 2) If I read the documentation correctly, when using StablePtr it is actually quite difficult to avoid undefined behaviour, at least in GHC(i). In particular, a double-free on a StablePtr yields undefined behaviour. However, when called twice on the same value, newStablePtr yields the same StablePtr in GHC(i). E.g.: module Main where import Foreign foo x y = do p1 <- newStablePtr x p2 <- newStablePtr y print $ castStablePtrToPtr p1 == castStablePtrToPtr p2 freeStablePtr p1 freeStablePtr p2 -- potential double free! main = let x = "Hello, world!" in foo x x -- undefined behaviour! prints "True" under GHC(i), "False" from Hugs. Considering that foo and main might be in different packages written by different authors, this makes correct use rather complicated. Is this behaviour (and the consequential undefinedness) intentional? With kind regards, Remi Turk [1] http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.6.0.1/Foreign-…

2 3

Protect my email address
by asakizi nji augustine 25 Dec '12

25 Dec '12

My email address is njihi5(a)yahoo.com

1 0

Rationale of capi?
by Lauri Alanko 07 Oct '12

07 Oct '12

Hello. GHC 7.6 now supports a "capi" calling convention which allows "function-like" macros to be invoked from Haskell code with "foreign import". To me this seems like rather odd design. The advantage of pure ABI-level FFI specifications (the standard Haskell FFI) is that wrappers can be generated in pure assembly by the Haskell compiler itself and there is no dependence on the C language. In contrast, "capi" requires the wrapper to be produced by a C compiler since the wrapped macro can expand to an arbitrary C expression. My question is: if the Haskell compiler is to support FFI wrappers that require a C compiler, why then are the wrappers so limited in functionality? The "capi" calling convention only supports function-like macros, i.e. ones that take expression arguments and expand into an expression. But there are many other kinds of macros, too: ones whose arguments are types or identifiers, and that may expand into a declaration or a statement. In fact, function-like macros are (or should be) a rarity, since inline functions serve the same purpose better. So when a well-designed C API has public macros, these macros are usually _not_ function-like. But using these from Haskell still requires writing some wrapper C functions (or, now, wrapper macros!) manually. Not a big deal, but then again, writing wrappers in C for function-like macros wasn't a big deal previously, either. So to me "capi" seems to buy very little, and it only supports strangely specific needs. If a Haskell implementation is to support FFI wrappers that must be compiled via C, a much more general solution would have been to allow arbitrary inline C code (instead of just the name of a macro) in the definition of the wrapper. I can't see that costing much more than the current design, and its benefits seem much greater. So am I missing something here? Lauri

2 1

addForeignPtrFinalizer - finalizers run in FIFO or LIFO order?
by Henning Thielemann 18 Aug '12

18 Aug '12

The doc of base-4.5:Foreign.ForeignPtr.addForeignPtrFinalizer states: "This function adds a finalizer to the given foreign object. The finalizer will run before all other finalizers for the same object which have already been registered." I do addForeignPtrFinalizer finalize1 fp addForeignPtrFinalizer finalize2 fp and let the finalizers print something when they are started. I get the output: finalizer1 finalizer2 This indicates that the newly added finalizer is run _after_ the finalizers that are already registered. Is this a documentation bug or a bug in the base library?

2 4

Static non-exported stubs?
by Lauri Alanko 17 Jun '12

17 Jun '12

Hello. I'm having a minor annoyance with the FFI, and was wondering if there was a better solution available. > {-# LANGUAGE ForeignFunctionInterface #-} > module FFITest where > import Foreign Suppose we are interfacing with a foreign library that uses callbacks, for instance, suppose we have "void register_callback(void (*callback)(void));" > foreign import ccall "register_callback" > registerCallback :: FunPtr (IO ()) -> IO () And we have a Haskell function that we want to register: > myCallback :: IO () > myCallback = undefined So how do we do this? The simplest option is to use a dynamic wrapper: > foreign import ccall "wrapper" wrapCallback :: IO () -> IO (FunPtr (IO ())) > registerMy :: IO () registerMy > = wrapCallback myCallback >>= registerCallback However, this is not really ideal: * We don't have a single global FunPtr, but we have to create a new one as an IO action. If we do the registration many times, we end up creating multiple wrappers for the same Haskell function, which is a bit wasteful. * Further, since the the FunPtr has been dynamically allocated, we have to remember to ensure that freeHaskellFunPtr gets called when the callback is no longer used. * Finally, I'm rather uncomfortable with the deep, deep magic that dynamic wrappers have to resort to to create new entry points at runtime. Since I'm registering a static top-level function, I shouldn't be having any of these problems. And indeed, I can get a FunPtr for the function... by exporting it first: > foreign export ccall "my_callback" myCallback :: IO () > foreign import ccall "&my_callback" myCallbackPtr :: FunPtr (IO ()) > > registerMy' :: IO () > registerMy' = registerCallback myCallbackPtr So this works, but it's annoying. I need to write redundantly two almost similar-looking foreign declarations, and this gives the impression of a strange hack instead of a normal conversion. Worst of all, I'm forced to pollute the symbol namespace by exporting my function as a symbol with external linkage. But I don't need my callback to be visible as a symbol to foreign code! I just need its address so I can pass it to the registration function. This is a very minor thing, but this seems like a very common use case so it's strange that there doesn't seem to be direct support for it. Is there really no way to tell the compiler to create a _static_ stub for a Haskell function and return the address of that stub, but _not_ export it as a symbol? Thanks, Lauri

1 0

[FFI] interference of FFI with poll(3)?
by Nick Rudnick 29 Apr '12

29 Apr '12

Dear all, after noticing problems with libssh2, and trying to fix this myself, I ran into a strange experience which I wish to get an explanation for. After compiling an OpenSSH server and a raw C libssh2 (for comparison) with debug messaging, I with support of the libssh2 community was able to trace the problem back to a call to poll(3) in session.c::_libssh2_wait_socket(), rc = poll(sockets, 1, has_timeout?ms_to_next: -1); where sockets consists of a single socket, session->socket_fd. This is roughly a polling with timeout for the connection – and, with the Haskell FFI, an error 4 / EINTR / Interrupted system call is thrown, and I was explained that this probably is caused by another signal of the same code unit. Not finding anything, I at the end extended libssh2 by a function, LIBSSH2_API void libssh2_test(void){ struct sockaddr_in sin; LIBSSH2_SESSION *session; const char *fingerprint; LIBSSH2_CHANNEL *channel; const unsigned long hostaddr= htonl(0x7F000001); const char *username= "i"; const char *keyfile1="/home/i/.ssh/id_rsa.pub"; const char *keyfile2="/home/i/.ssh/id_rsa"; const char *password= "D0r1nha23"; int got= 0; int sock= socket(AF_INET, SOCK_STREAM, 0); sin.sin_family= AF_INET; sin.sin_port= htons(22); sin.sin_addr.s_addr= hostaddr; if(connect( sock, (struct sockaddr*)(&sin), sizeof(struct sockaddr_in) ) != 0 ) { fprintf(stderr, "failed to connect!\n"); return; } session= libssh2_session_init(); libssh2_trace(session,~0); if(libssh2_session_handshake(session, sock)) { _libssh2_debug(session, LIBSSH2_TRACE_TRANS , "Failure establishing SSH session" ); return; } fingerprint= libssh2_hostkey_hash(session, LIBSSH2_HOSTKEY_HASH_SHA1); libssh2_userauth_list(session, username, strlen(username)); // ?? if(libssh2_userauth_publickey_fromfile( session , username , keyfile1 , keyfile2 , password )) { _libssh2_debug(session, LIBSSH2_TRACE_TRANS , "\tAuthentication by public key failed!" ); return; } else { _libssh2_debug( session, LIBSSH2_TRACE_TRANS , "\tAuthentication by public key succeeded." ); if(!(channel= libssh2_channel_open_session(session))) { _libssh2_debug( session, LIBSSH2_TRACE_TRANS , "Unable to open a session" ); return; } else { libssh2_channel_setenv(channel, "FOO", "bar"); if(libssh2_channel_request_pty(channel, "vanilla")) { _libssh2_debug( session, LIBSSH2_TRACE_TRANS , "Failed requesting pty" ); } else { if(libssh2_channel_shell(channel)) { _libssh2_debug( session, LIBSSH2_TRACE_TRANS , "Unable to request shell on allocated pty" ); } else { if(channel){ libssh2_channel_free(channel); channel= NULL; } } } } } libssh2_session_disconnect( session , "Normal Shutdown, Thank you for playing" ); libssh2_session_free(session); close(sock); libssh2_exit(); return; } and called it by foreign import ccall unsafe "libssh2_test" libssh2Test:: IO () as well as {# context lib="ssh2" prefix="libssh2" #} {# fun test as test { } -> `()' #} With both approaches, I still got the same EINTR error, while coalling libssh2_test() from C works completely flawless. Is it possible that an interfering signal comes from the FFI? If yes, is there a workaround? Grateful for any kind of enlightenment... :-) Thanks a lot in advance, Nick

2 2

[FFI] interference of FFI with poll(3)?
by Nick Rudnick 28 Apr '12

28 Apr '12

Dear all, after noticing problems with libssh2, and trying to fix this myself, I ran into a strange experience which I wish to get an explanation for. After compiling an OpenSSH server and a raw C libssh2 (for comparison) with debug messaging, I with support of the libssh2 community was able to trace the problem back to a call to poll(3) in session.c::_libssh2_wait_socket(), rc = poll(sockets, 1, has_timeout?ms_to_next: -1); where sockets consists of a single socket, session->socket_fd. This is roughly a polling with timeout for the connection – and, with the Haskell FFI, an error 4 / EINTR / Interrupted system call is thrown, and I was explained that this probably is caused by another signal of the same code unit. Not finding anything, I at the end extended libssh2 by a function, LIBSSH2_API void libssh2_test(void){ struct sockaddr_in sin; LIBSSH2_SESSION *session; const char *fingerprint; LIBSSH2_CHANNEL *channel; const unsigned long hostaddr= htonl(0x7F000001); const char *username= "i"; const char *keyfile1="/home/i/.ssh/id_rsa.pub"; const char *keyfile2="/home/i/.ssh/id_rsa"; const char *password= "D0r1nha23"; int got= 0; int sock= socket(AF_INET, SOCK_STREAM, 0); sin.sin_family= AF_INET; sin.sin_port= htons(22); sin.sin_addr.s_addr= hostaddr; if(connect( sock, (struct sockaddr*)(&sin), sizeof(struct sockaddr_in) ) != 0 ) { fprintf(stderr, "failed to connect!\n"); return; } session= libssh2_session_init(); libssh2_trace(session,~0); if(libssh2_session_handshake(session, sock)) { _libssh2_debug(session, LIBSSH2_TRACE_TRANS , "Failure establishing SSH session" ); return; } fingerprint= libssh2_hostkey_hash(session, LIBSSH2_HOSTKEY_HASH_SHA1); libssh2_userauth_list(session, username, strlen(username)); // ?? if(libssh2_userauth_publickey_fromfile( session , username , keyfile1 , keyfile2 , password )) { _libssh2_debug(session, LIBSSH2_TRACE_TRANS , "\tAuthentication by public key failed!" ); return; } else { _libssh2_debug( session, LIBSSH2_TRACE_TRANS , "\tAuthentication by public key succeeded." ); if(!(channel= libssh2_channel_open_session(session))) { _libssh2_debug( session, LIBSSH2_TRACE_TRANS , "Unable to open a session" ); return; } else { libssh2_channel_setenv(channel, "FOO", "bar"); if(libssh2_channel_request_pty(channel, "vanilla")) { _libssh2_debug( session, LIBSSH2_TRACE_TRANS , "Failed requesting pty" ); } else { if(libssh2_channel_shell(channel)) { _libssh2_debug( session, LIBSSH2_TRACE_TRANS , "Unable to request shell on allocated pty" ); } else { if(channel){ libssh2_channel_free(channel); channel= NULL; } } } } } libssh2_session_disconnect( session , "Normal Shutdown, Thank you for playing" ); libssh2_session_free(session); close(sock); libssh2_exit(); return; } and called it by foreign import ccall unsafe "libssh2_test" libssh2Test:: IO () as well as {# context lib="ssh2" prefix="libssh2" #} {# fun test as test { } -> `()' #} With both approaches, I still got the same EINTR error, while coalling libssh2_test() from C works completely flawless. Is it possible that an interfering signal comes from the FFI? If yes, is there a workaround? Grateful for any kind of enlightenment... :-) Thanks a lot in advance, Nick

1 0

Marshalling C unions
by Nabil Alsharif 14 Apr '11

14 Apr '11

Hi everybody, I know this sounds like an issue many have faced before me, but good old google didn't come up with any helpful results. The basic problem is that I need to marshal a union so I can pass it to a C function via FFI. So to make sure I have my head wrapped around this correctly, say I have a union like so: typedef union { int i; char c; } my_union; This would typically be represented in Haskell as: data myUnion = I CInt | C CChar My question is how would you marshall (define an Storable instance for) myUnion into my_union? It's my understanding that an instance my_union would take up sizeof(int) bytes in memory, i.e. the size of it's largest member. So to store this we would write something along the lines of: instance Storable myUnion where size _ = #{size my_union} -- <-- hsc2hs shortcut alignment _ = alignment undefined::CInt -- <-- What should this really be? peek ptr = do -- <-- How are you supposed to know which element to extract? poke ptr (I i) = poke ptr i -- <-- Or should this be #{poke my_union, i} ptr i ? poke ptr (C c) = poke ptr c I hope this clear. I appreciate all the help. If this question has already been answered, which I'm sure it has, please point me to right spot. Thanks again for everyone's time. Nabil Alsharif.

2 1

Re: FFI, DLL Linking, Windows Haskell Platform 2010
by Nabil Alsharif 04 Apr '11

04 Apr '11

Thank you very Mr. Thielemann. I got everything working under linux, ghc links to distorm and the library compiles and works. After a little investigation I found out that, under windows, distorm is compiled using MSVC and I had used MSVC to compile the test C program I had written to make sure I could link to distorm before I started messing with ghc and FFI. The catch is that if I try to compile the test C program with gcc under windows it fails :-(. So I guess in the end this want really a ghc issue and it's more of a microsoft awesomeness issue, and made worse by distorm's support for mingw being broken. Thanks for the Cabal link, I'm gonna write a Cabal package for this sooner or later. The reason for using distorm is because we need to replace the disassembler pack with something more versatile. Nabil Alsharif. On 04/03/2011 02:57 PM, Henning Thielemann wrote: > Nabil Alsharif schrieb: > >> The issue is when I try to compile the library the linker goes haywire: >> C:\Users\tantalum\Documents\Research\distorm_test>ghc --make Main.hs >> [2 of 2] Compiling Main ( Main.hs, Main.o ) >> Linking Main.exe ... >> .\Distorm3.o:fake:(.text+0x11b): undefined reference to `distorm_version' >> collect2: ld returned 1 exit status > > You must link the distorm library into the executable. Say: > > $ ghc -ldistorm --make Main.hs > > It should work this way on Unix at least. > > >> C:\Users\tantalum\Documents\Research\distorm_test>ghc --make Main.hs -l distorm3 > I don't know whether the argument order matters. > >> Linking Main.exe ... >> C:\Program Files (x86)\Haskell Platform\2010.2.0.0\mingw\bin\ld.exe: cannot find >> -lC:\Users\tantalum\AppData\Local\Temp\ghc5976_0\ghc5976_0.o >> collect2: ld returned 1 exit status >> >> Any ideas or suggestions? What is that temporary object file for? > You may also try to let Cabal handle the calling of GHC. You may start > with an existing C library binding and adapt it to your needs. E.g. > http://code.haskell.org/jack/jack.cabal > > > You may also be interested in the disassembler package at Hackage: > http://hackage.haskell.org/package/disassembler-0.1.0.1

1 0

Possible to call Haskell function from C and return a struct by value?
by sframe 30 Mar '11

30 Mar '11

Greetings, I am a Haskell novice, but I have written some Haskell functions and would like to call them from C++. The functions perform world coordinate system conversions like the following: data Geocentric = Geocentric { ecefX :: Double, ecefY :: Double, ecefZ :: Double } deriving (Show) data Geodetic = Geodetic { latitude :: Double, longitude :: Double, height :: Double } deriving (Show) geocentricToGeodetic :: Geocentric -> Geodetic geocentricToGeodetic geocentric = Geodetic lat lon height where ... ... lat = ... lon = ... height = ... I would like to call these functions from C++ using FFI, and have figured out how to wrap using FFI to accept and return primitive types: xGeocentricFromGeodetic :: CDouble -> CDouble -> CDouble -> CDouble xGeocentricFromGeodetic lat lon height = realToFrac (ecefX (geodeticToGeocentric (Geodetic (realToFrac lat) (realToFrac lon) (realToFrac height)))) foreign export ccall xGeocentricFromGeodetic :: CDouble -> CDouble -> CDouble -> CDouble Would there be a way to accept a C struct and return a C struct by value, something like this: struct Geocentric { double ecefX; double ecefY; double ecefZ; }; struct Geodetic { double lat; double lon; double height; }; With a method like the following: Geocentric geocentricToGeodetic (const Geodetic & geod); I have investigated the Storable class, but it seems as though this is intended to be used with pointers. In addition, it seems that most of the examples I have found deal with calling C code from Haskell and not vice-versa. Does anyone know if this can be achieved, and if so how? Any help is much appreciated. -- View this message in context: http://haskell.1045720.n5.nabble.com/Possible-to-call-Haskell-function-from… Sent from the Haskell - FFI mailing list archive at Nabble.com.

1 0