Hi, I think that one may view a "static_wrapper" import as a pair of an export like the one you wrote and an import of the address of the exported function (this is useful because usually it is convenient to install the handler on the Haskell side). Perhaps that's a better way to explain its meaning, rather then the long-winded example that I wrote. Thanks! In practice, the foreign export generates slightly less direct code, because the C code follows 2 indirections: first we enter the closure for "cbind", and then _that_ code enters the closure for the actual Haskell function. Perhaps with sufficient optimization on the C side this can be avoided although I don't think that it happens at the moment. In terms of notation, I like the directness of the "static_wrapper" declaration (although not so much the "static_wrapper" name!) because it avoids duplication, thus reducing clutter and potential errors. -Iavor On Mon, Mar 15, 2010 at 3:56 PM, Tyson Whitehead <twhitehead@gmail.com> wrote:
On March 15, 2010 12:48:02 Iavor Diatchki wrote:
I have implemented a small extension to the FFI which allows for "static_wrapper" imports. These are a variation on "wrapper" imports that do not use run-time code generation. This is important in security sensitive contexts because it avoids executable data. While "static_wrapper" imports are less general then "wrapper" imports, they can be used to install Haskell handlers in many C libraries where callbacks have an extra "user-data" parameter (e.g., GTK signal handlers).
Hi Iavor,
Would not the following also do what you want
foreign export ccall "haskellCIntCInt" \ cbind :: CInt -> StablePtr (CInt -> IO CInt) -> IO CInt
cbind :: a -> StablePtr (a-> IO b) -> IO b cbind x f = deRefStablePtr f >>= (\f_ -> f_ x)
On the C side you would then have something like
register_callback(haskellCIntInt,<wrapped haskell closure>)
where <wrapped haskell closure> would be a stable pointer of type StablePtr (CInt -> IO CInt) generated on the haskell side via
newStablePtr <haskell closure>
and passed to the C code.
Cheers! -Tyson