- C2hs - Haskell.org

darcs patch: alignment keyword support
by ron＠gamr7.com 23 Oct '09

23 Oct '09

Thu Oct 22 17:38:09 CEST 2009 ron(a)gamr7.com * alignment keyword support

1 0

Re: [C2hs] Function Hooks and Calling Convention
by Duncan Coutts 22 Sep '09

22 Sep '09

On Tue, 2009-09-22 at 10:17 -0700, Thomas DuBuisson wrote: > > Though actually that might not help for the kernel headers because I > > think they do not declare the regparam calling convention and just rely > > on gcc flags when compiling. > > You are correct - the call convention has to be declared manually. > There is no reasonable way for c2hs to learn it. Do you have any suggestion for that? The information would have to be supplied somehow. I guess as command line parameters to c2hs. I guess we just need to mirror gcc in that respect, to accept some of the gcc flags that globally modify the ABI. c2hs --gcc-abi-mode=-fregparam=3 or whatever. Of course it also needs ghc to support that FFI calling convention, which I understand you've made as a local ghc modification. The same applies to stdcall vs ccall however, so it's generally useful even if you never contribute the regparam calling convention. > >> In the end the solution I have is to manually write the above C > >> section and the foreign import call using a regparm3 calling > >> convention. This isn't to say c2hs isn't used - its still hugely > >> helpful (so long as the headers remain easy to convert to ANSI C), but > >> just my quick experience. > > > > BTW, what do you mean about ANSI C? > > I meant there exists at least one aspect (perhaps a bug) to the kernel > headers that cause an error when c2hs tries to parse the headers. In > the FC11 2.6.30 headers they use an enum when declaring an extern > function prototype - without declaring the enum (timers.h). The > solution is to #include <linux/hrtimers.h>, which contains the enum > declaration. Ah, and gcc accepts this without warning? Perhaps you can boil down a test case and submit it. I tried hard when making the C parser to cover all the GNU extensions and I ran it over all the kernel sources for some older kernel release. So it's worth fixing these things to maintain its usability. > > So yes, I think all these issues are solvable. As usual the difficulty > > is finding enough people with enough time to actually do the work. I > > think c2hs could become the standard Haskell ffi binding tool, taking > > over from hsc2hs, but it needs a bit of love. > > FWIW, hsc2hs is entirely unusable for this work as it builds a .c file > that will generate the .hs file. I couldn't get this to work for > kernel bindings as one build (the generating .c file) needs things > like stdlibs while the other (the kernel) absolutely can not have such > things. All sorts of conflicts occur, such as redefinition of basic > type by the kernel headers. That's an interesting point I had not though of before. It's a bit like cross-compilation really, which is another case where in principle c2hs should do fine but where hsc2hs cannot help. Duncan

2 2

Function Hooks and Calling Convention
by Thomas DuBuisson 22 Sep '09

22 Sep '09

Playing with function hooks, I've found two issues that draw my ire. FYI, this is more of a partial experience report than a question. For an example, let us discuss the kernel function "pci_register_driver", which is actually a macro and thus not handled by the function hooks. The first step in fixing this is a CPP section: #c inline int pci_register_driver2(pci_dev_t d) { pci_register_driver(d); } #endc So I'd call this experience number 1 - it is entirely possible to automatically generate wrapper functions for macros ( {#macro ...}? or even {#fun ...} handling macros too). Perhaps there's not enough interest for anyone to make this change but I expect this to come up more and more often. I'll note that this is very similar to the issue of importing pure macros (macros that don't wrap a function call), which would be a nice feature. I can now write the hook and c2hs will parse things ok: {#fun pci_register_driver2 as ^ {id `PCIDriver' } -> `Int' id#} generating a foreign import: foreign import ccall safe "pci.chs.h pci_register_driver2" pciRegisterDriver'_ :: ((PCIDriver) -> (IO CInt)) And all seems well... except that I'm aiming to use this in interfacing with the Linux kernel. The generated *.chs.h file will/must be compiled into an object file using the Linux build system, which defaults to a regparm3 calling convention. Why does c2hs automatically assume its a ccall? I could really use an opportunity to insert an alternate convention. In the end the solution I have is to manually write the above C section and the foreign import call using a regparm3 calling convention. This isn't to say c2hs isn't used - its still hugely helpful (so long as the headers remain easy to convert to ANSI C), but just my quick experience. Thomas

2 2

C2hs and c 'struct' declarations
by Thomas DuBuisson 21 Sep '09

21 Sep '09

Hello c2hs! I'm having an issue when using get and set hooks. Take the following example c code: typedef struct { int x; int y; } point; This has easy bindings: {#pointer *point as Point#} getX :: Point -> IO CInt getX = {#get point->x#} setX :: Point -> CInt -> IO () setX p i = {#set point->x} p i But what if the header file doesn't typedef? struct point { int x; int y; }; It seems c2hs can't bind to these data structures, the straight forward way of replacing 'point' with 'struct point' isn't parsed. Any combination of parens or quotes to make it parse as a single token haven't worked - also I see nothing in the tutorial. Any advice? Thomas

2 2

Custom default marshalers + binding variables
by Maciej Piechotka 29 Aug '09

29 Aug '09

Hello. First I'd like to thank for great job c2hs is doing. However I find a few points where it could be better. 1. New marshallers. Sometimes pointer + defaults are not good enough. Maybe something like {#marshaller cname [into hname] in='hname[-*]' out='hname[-*]#} would be helpful. Possibly overriding default marshallers would also be helpful (for example if string is encoded in UTF-8). 2. Most of the C2HS library can be done as default elements. What's the point of defining cIntConv as fromIntegral? Why not simply not insert fromIntegral or Prelude.fromIntegral? 3. I find that many times I'd like to insert a simply variable into argument. So I find out that: {#fun ... { withNullPtr- `Ptr ...', ... } -> ...#} where withNullPtr f = f nullPtr I guess that {#fun ... { nullPtr% `Ptr ...', ... } -> ...#} or similar or {#fun ... { ($nullPtr)- `Ptr ...' } -> ...#} would be helpful (the second notation allows any arbitrary Haskell function to be executed which is also usefult. Regards

1 0

A bug of c2hs lexer?
by Andy Stewart 22 Aug '09

22 Aug '09

Hi all. When i run command "c2hs -d trace $(pkg-config --cflags vte | sed 's/-I/-C-I/g') /usr/include/vte/vte.h /test/Download/VteBinding/Vte.chs" i got below error: ------------------------------> error start <------------------------------ Attempting to read file `/test/Download/VteBinding/Vte.chs'... ...parsing `/test/Download/VteBinding/Vte'... ...successfully loaded `/test/Download/VteBinding/Vte'. Invoking cpp as `cpp -x c -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/include/pango-1.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng12 /test/Download/VteBinding/Vte.chs.h'... Attempting to read file `Vte.i'... ...parsing `Vte.i'... ...name analysis of `Vte.i'... ...error(s) detected in `Vte.i'. c2hs: C header contains errors: <built-in>:1: (column 1) [ERROR] >>> error Lexical error ! The character '#' does not fit here. ------------------------------> error end <------------------------------ And i found same problem at http://hackage.haskell.org/trac/gtk2hs/ticket/1101 It's a bug of c2hs? My locale is: ------------------------------> locale start <------------------------------ LANG=zh_CN.UTF-8 LC_CTYPE="zh_CN.UTF-8" LC_NUMERIC="zh_CN.UTF-8" LC_TIME="zh_CN.UTF-8" LC_COLLATE="zh_CN.UTF-8" LC_MONETARY="zh_CN.UTF-8" LC_MESSAGES="zh_CN.UTF-8" LC_PAPER="zh_CN.UTF-8" LC_NAME="zh_CN.UTF-8" LC_ADDRESS="zh_CN.UTF-8" LC_TELEPHONE="zh_CN.UTF-8" LC_MEASUREMENT="zh_CN.UTF-8" LC_IDENTIFICATION="zh_CN.UTF-8" LC_ALL= ------------------------------> locale end <------------------------------ Thanks! -- Andy

1 0

c2hs / Language.C feature to discover cdecl / stdcall
by Duncan Coutts 02 Apr '09

02 Apr '09

It was pointed out to me yesterday that it would be rather useful if c2hs could automatically work out if the ffi import for a {# call/fun #} hook should be ccall or stdcall calling convention. It would be useful because some Windows libs use stdcall. Some, otherwise portable, libs use ccall on most platforms and stdcall on Windows. OpenGL is an example of the latter. In principle this is possible because, in GNU C at least, the calling convention in indicated in a function __attribute__((__stdcall__)). So the first job would be for Language.C to keep the __attribute__'s in the abstract syntax tree. They already get parsed, but at least last time I looked they were not entered into the AST. The attribute syntax is pretty uniform so a generic representation in the AST would be fine. Any code that interpreted the attributes would just have to match on known string values. That's the most work. With that done it should be relatively straightforward for c2hs to inspect the set of attributes to see if it's got a stdcall attribute and if so generate an appropriate ffi import. Duncan

2 2

How to access inside a union using #set
by Mark Wassell 02 Apr '09

02 Apr '09

Hello, I have the following: typedef struct tagKEYBDINPUT { WORD wVk; WORD wScan; DWORD dwFlags; DWORD time; ULONG_PTR dwExtraInfo; } KEYBDINPUT, *PKEYBDINPUT; typedef struct tagINPUT { DWORD type; union {MOUSEINPUT mi; KEYBDINPUT ki; HARDWAREINPUT hi; }; }INPUT, *PINPUT; and in a chs file: sendChar :: HWND -> Char -> IO () sendChar win ch = do allocaBytes ( {#sizeof INPUT#}) $ \ptr -> {#set INPUT.type #} ptr 0 {#set INPUT.ki.wVk #} ptr 0 {#set INPUT.ki.dwFlags #} ptr 0 c2hs comes up with Test1.chs:27: (column 37) [ERROR] >>> error Unknown member name! The structure has no member called `ki'. The structure is defined at ("sendinput.h",35,9). Test1.chs:26: (column 37) [ERROR] >>> error Unknown member name! The structure has no member called `ki'. The structure is defined at ("sendinput.h",35,9). How do I address fields inside the union? Cheers Mark

2 1

ANNOUNCE: c2hs 0.16.0
by Duncan Coutts 28 Feb '09

28 Feb '09

All, c2hs version 0.16.0 is out and is available from hackage http://hackage.haskell.org/cgi-bin/hackage-scripts/package/c2hs What is c2hs ============ The c2hs tool assists in the development of Haskell bindings to C libraries. It extracts interface information from C header files and generates Haskell code with foreign imports and marshaling. The major advantages of using c2hs compared to writing foreign imports by hand (or using hsc2hs) are: * Cross-language type safety: C functions are imported with the correct Haskell types. * Saves time: boilerplate marshaling code is generated. Changes in this release ======================= The major change in this release is that it now uses the Language.C library. This brings the code full circle. Benedikt Huber split out and developed the Language.C library from the C parser I originally wrote for c2hs some years ago. Other changes since 0.15.x: * Works better on OSX, it now uses gcc -E to do the pre-processing of C header files. Previously it used cpp, however on OSX the cpp program appears to operate in an antiquated compatibility mode. * "enum hooks" are now implemented but not yet documented * A couple fixes in the default mapping of C names to Haskell names. * A number of other bugs fixes. Credits ======= Benedikt Huber gets the credit for majority of the work in this release. Thanks also to John Lato for numerous cleanup patches. Links ===== Home page: http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ Bug tracker: http://hackage.haskell.org/trac/c2hs/ Duncan

1 0

patch applied (c2hs): TAG 0.16.0
by Duncan Coutts 28 Feb '09

28 Feb '09

Sat Feb 28 05:28:23 PST 2009 Duncan Coutts <duncan(a)haskell.org> tagged 0.16.0 View patch online: http://darcs.haskell.org/c2hs/_darcs/patches/20090228132823-adfee-4a1db0daf…

1 0