- FFI - Haskell.org

Re: Generating Function Prototypes
by Ashley Yakeley 03 Jul '02

03 Jul '02

At 2002-07-03 02:57, Malcolm Wallace wrote: >The "proper" way to do it is to write the prototype yourself in a >C header file (or use an existing header), and then use a compiler-specific >mechanism to #include it. OK I'll do this. >The nhc98 compiler does generate a prototype (ghc does not). However, >although this works quite well in the general case, occasionally the >generated prototype may not be compatible with the real C type of >the function (e.g. it cannot guess the `const' attribute). This might be fixed by creating a ConstPtr type. Class Storable could then be extended: class Storable a where ... constPeekElemOff :: ConstPtr a -> Int -> IO a constPeekByteOff :: ConstPtr a -> Int -> IO a constPeek :: ConstPtr a -> IO a castToConst :: Ptr a -> ConstPtr a castAwayConst :: ConstPtr a -> Ptr a -- possibly unsafe -- Ashley Yakeley, Seattle WA

1 0

RE: Generating Function Prototypes
by Simon Marlow 03 Jul '02

03 Jul '02

> I've been having trouble with an imported function that returns > Int64/"long long". Haskell doesn't generate a prototype, so > regular 'int' > type is assumed. > > Why doesn't Haskell generate a prototype from the 'foreign import' > declaration, as part of the -fvia-C compilation? When the > prototype is > omitted, a default one is assumed. Surely FFI can improve on > the default > with the information given by the 'foreign import' declaration? > > In the mean time, how do I work around the problem and provide a > prototype myself? In GHC, you bring a prototype into scope either by using the string in the foreign import declaration to specify a header file, or you specify a header file in a command-line flag (-#include "foo.h" for example). The command-line flag can be also given in the source file using an OPTIONS pragma. Generating a prototype is not possible, I'm afraid (see previous discussion for the gory details). Cheers, Simon

1 0

RE: More C interfacing issues
by Simon Marlow 03 Jul '02

03 Jul '02

> -----Original Message----- > From: Alastair Reid [mailto:reid@reid-consulting-uk.ltd.uk] > Sent: 02 July 2002 18:34 > To: Ian Lynagh > Cc: ffi(a)haskell.org > Subject: Re: More C interfacing issues > > > > > Firstly, some ncurses calls return a *WINDOW and others take one as > > an argument but you never actually look at the contents of one > > yourself. I have defined "data Window = Window" and am using Ptr > > Window for the types of these. However, this means I get a warning > > about an unused constructor. Is there a better way to do this? > > Hugs supports: > > data Window > > and I believe GHC and NHC do too. (Malcolm, SimonM: please > shout if I overstate.) Yes, GHC does. > > > Secondly, does anyone have any suggestions on how to provide an > > interface to this? > > > void getyx(WINDOW *win, int y, int x); > > > The getyx macro places the current cursor position of the given > > window in the two integer variables y and x. > > > The type would probably ideally be "Ptr Window -> IO (CInt, CInt)". > > The easy way is to use GreenCard (the other ffi frontends may be of > use too). > > Or, you can do what GreenCard does which is to add 3 wrapper functions > more or less like this: What's wrong with just doing this in the plain FFI? data Window foreign import ccall "getyx" getyx :: Ptr Window -> Ptr CInt -> Ptr CInt -> IO () niceGetYX :: Ptr Window -> IO (CInt, CInt) niceGetYX win = alloca $ \py -> alloca $ \px -> do getyx win py px y <- peek py x <- peek px return (x,y) Have I missed something? Cheers, Simon

2 1

More C interfacing issues
by Ian Lynagh 03 Jul '02

03 Jul '02

Hi all, A couple more questions. Firstly, some ncurses calls return a *WINDOW and others take one as an argument but you never actually look at the contents of one yourself. I have defined "data Window = Window" and am using Ptr Window for the types of these. However, this means I get a warning about an unused constructor. Is there a better way to do this? Secondly, does anyone have any suggestions on how to provide an interface to this? void getyx(WINDOW *win, int y, int x); The getyx macro places the current cursor position of the given window in the two integer variables y and x. The type would probably ideally be "Ptr Window -> IO (CInt, CInt)". Thanks Ian

4 5

Getting constants from #defines
by Ian Lynagh 27 Jun '02

27 Jun '02

Hi all, I was expecting something like foreign import ccall unsafe "static ncurses.h ERR" cERR :: CInt to allow me to access the value of ERR (a #define) as cERR. However, as far as I can tell GHC is trying to compile this as if ERR was a function. This seems silly to me as a function can always be defined with a type "a -> b" where "a", "b" or both can be "()" so this should be unambiguous. Am I misunderstanding what is going on here? Thanks Ian

2 1

RE: Getting constants from #defines
by Simon Marlow 26 Jun '02

26 Jun '02

> I was expecting something like > > foreign import ccall unsafe "static ncurses.h ERR" cERR :: CInt > > to allow me to access the value of ERR (a #define) as cERR. > However, as > far as I can tell GHC is trying to compile this as if ERR was a > function. This seems silly to me as a function can always be defined > with a type "a -> b" where "a", "b" or both can be "()" so this should > be unambiguous. The FFI doesn't have support for grabbing the values of #defines - you need to use another tool to do this (autoconf, hsc2hs, c2hs, green-card, hdirect, whatever). The declaration above binds cERR to a function of zero arguments. i.e. in C-speak this would be void cERR( void ); A function of type a->b has one argument of type 'a', not zero. Cheers, Simon

2 1

Greencard-Canada-Aupair
by Greencard 25 Jun '02

25 Jun '02

1 0

Re: Problem with FFI?
by Alastair Reid 21 Jun '02

21 Jun '02

[reply redirected to ffi(a)haskell.org] John Meacham <john(a)repetae.net> writes: > I may be missing something obvious here, but from the current FFI > spec it appears that it is impossible to create libraries in haskell > which are meant to be called from c code without running into > undefined behavior. The problem is in the definition of hs_init() > and hs_exit() . now, it is acceptable to have hs_init and hs_exit > called in the initialization and finalization of your library, but > the problem arrises when you link against more than one library > which is implemented in haskell, suddenly whichever library is > initialized secondly segfaults! (or whatever undefined behaviour > means.). programs could suddenly stop working when a library is > changed from a c implementation to a haskell one, which seems to be > a bad thing. Hmmm, I see what you mean. > proposed fix: allow nested calls to hs_init, hs_exit, a counter is > incremented when hs_init is called more than once, and decremented > on hs_exit. only the last call to hs_exit will actually do whatever > needs to be done. The hs_init function takes arguments - what if each call to hs_init specifies a different set of arguments? How about: hs_set_hs_argv (int argc, char *argv[]); hs_set_prog_argv (int argc, char *argv[]); hs_init (); hs_exit (); Where: hs_set_hs_argv sets command line parameters for the Haskell runtime system It can be called at most once and that call must be before the first call to hs_init Warning! The flags are not remotely portable between different Haskell runtimes. hs_set_prog_argv sets arguments seen by getProgName and getArgs It can be called at most once and that call must be before the first call to hs_init hs_init initializes the Haskell runtime It can be called multiple times and must be called before the first call to any function exported by the Haskell code. hs_exit finalizes the Haskell runtime hs_init and hs_exit are required to satisfy the usual bracketing rules: 1) At any time, the number of calls that have been made to hs_exit must be no more than the number of calls that have been made to hs_init. 2) If the number of calls to hs_exit is equal to the number of calls to hs_init, then no further calls to hs_init may be made. By the way, the name 'hs_exit' is a little confusing - I expected it to have an ExitCode argument. 'hs_fini' would better match its actual purpose. > note that this cannot be implemented by the programmer himself since > there might be several third party libraries also implemented in > haskell which an app wishes to link against. You can implement the modified API (or your modified semantics) quite readily as a little library which you link against your program. All you have to do is tweak the names a little (e.g., s/hs/HS/) to avoid name clashes. -- Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/

2 2

Real ZOO web site, welcome! ID<iilCkdvnhoo1ruj>
by Farmgirl10585 20 Jun '02

20 Jun '02

1 0

RE: Library archives
by Simon Marlow 19 Jun '02

19 Jun '02

> The questions that come up as I implement the ffi are mostly things > that are not clear from the spec. This is a particularily good > example of that - there's no example and the explanation is brief and > open to many interpretations. I could hunt through the archives and > guess at what the final decision was or I could ask for clarification > so that we all agree on what change is needed to the report (or I look > foolish when the appropriate section of the report is pointed out to > me). > > In this case, all I could find was a brief discussion with no final > conclusion. (Or maybe I missed the conclusion - the subject lines one > the messages are fairly uninformative so I skimmed old mail fairly > quickly.) See these threads, for example: http://www.haskell.org/pipermail/ffi/2001-February/000212.html http://www.haskell.org/pipermail/ffi/2001-May/000345.html Cheers, Simon

2 1