Hello, On Tue, Mar 16, 2010 at 3:22 PM, Simon Marlow <marlo...@gmail.com> wrote:
> It seems hard to justify adding this to GHC, since it's really just > syntactic convenience for a particular case. Traditionally syntactic sugar > for FFI declarations has been implemented in the preprocessing tools: c2hs > and hsc2hs, whereas the FFI extension itself is purposefully minimal. The fact that, at present, all GHC-compiled programs require an executable data segment is a fairly significant problem. For example, SE Linux policies need to be adjusted for all GHC-compiled programs, even if run-time code generation never actually happens. I decided to implement this as a GHC patch because it seems more primitive then the "wrapper" imports: it is a simpler feature which---if it was available---would have been sufficient in all the situations where I have needed to use a "wrapper" import. Furthermore, the code that is called by the adjustor thunks is essentially the function that we are exposing in a "static_wrapper" import, so it seems plausible that "wrapper" imports can be implemented on top of this, although I have not done this. I thought of implementing the feature as a preprocessor but it did not seem very easy to do because we need to parse Haskell types. Of course, I could have either hacked up a simple parser, or used some kind of a Haskell parsing library but that seemed very heavy-weight. Also, preprocessors tend to complicate the build system, result in confusing error messages, and make it difficult to work with modules in GHCi. As far as I can see, the notation that I used does not conflict with anything, except possibly importing a C function named "static_wrapper" without specifying a header file, which is already a problem with "wrapper" imports. This would not be the case if we used something which is not a valid C identifier (e.g., "static"). This seems like a small enough change to not require a separate flag. If we decided to use Tyson's suggested syntax, then we should probably add a flag. In any case, I think that moving away from executable data is important enough that I'd be happy with an extra flag. Thoughts? -Iavor > So at the moment we're slightly inclined not to put it in - but feel free to > make a compelling case. Note that as an extension in its own right it would > need its own flag, documentation etc. > > Cheers, > Simon > >> -Iavor >> >> >> >> >> >> >> >> >> On Mon, Mar 15, 2010 at 3:56 PM, Tyson Whitehead<twhiteh...@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 >>> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users