- C2hs - Haskell.org

Default Marshallers / Arbitrary expressions as marshallers
by Benedikt Huber 07 Nov '08

07 Nov '08

Hi again, I noted Gour filed a ticket for 'allowing arbitrary expressions as marshallers'. > http://hackage.haskell.org/trac/c2hs/ticket/13 This sounds interesting, but I wonder which would be the most sensible implementation strategy. Do you suggest to implement hs98 expressions using the existing framework ? Is there some existing code that could be reused ? Apart from that, I think the following additional default marshallers would make sense: a) If the hs type is defined in an {# enum ... #} hook and the C type is integral, use (fromEnum/toEnum . cIntConv) as default. b) If the hs type and C type match, and are of the form (Ptr a), use 'id' as default. This is really useful when working with opaque pointers, but maybe there are type-safety related reasons why this shouldn't be done. c) Additionally, we could allow the user to add other default marshallers, depending on the combination of hs/C type. If I recall correctly, Duncan had some ideas for this one ? best regards, benedikt

2 5

Re: c2hs + language.c
by Duncan Coutts 14 Oct '08

14 Oct '08

On Wed, 2008-08-20 at 18:36 +0200, Benedikt Huber wrote: > Hello ! > > I've set up a branch of c2hs using Language.C's parser and pretty > printer. > > http://code.haskell.org/~bhuber/c2hs > The branch also fixes a couple of bugs (#6,#8,#9,#12) and, as a small > bonus, implements enum define hooks (Bug #5). Woo hoo! When you're happy we should merge this into mainline c2hs. Which reminds me, I should fix #11. Duncan

4 3

Intented meaning of CDeclr
by Benedikt Huber 06 Aug '08

06 Aug '08

Hello, I've been trying to fix some bugs in c2hs, which all seem related to the definition of CDeclr. I'm not quite sure what the actual problem is, so maybe someone can help me out here. I'm referring to the lasted revision from darcs (0.15.2): The problem is that the Parser assumes that the leftmost indirection is represented outermost in the chain of CDeclrs. To illustrate, consider > char * x[]; "x is an array of pointers to char". The parser returns (simplified): > CPtrDeclr (CArrDeclr (CVarDeclr "x")) I'm not sure if this is an accidental mistake, but in the analysis code, it is assumed that the above declarator is represented as > CArrDeclr (CPtrDeclr (CVarDeclr "x")) which seems more plausible in my opinion. Should this be fixed in the parser ? Another confusing part: In src/C2HS/C/AST.hs, we find 424: -- * The qualifiers list in a `CPtrDeclr' may not be empty 437: CPtrDeclr [CTypeQual] -- indirections This sounds as if the type qualifiers (const,restrict,volatile) model indirections of pointers, which isn't true of course. This assumption apparently is used in src/C2HS/Gen/Bind.hs: 1066ff: > case declr of > (Just (CPtrDeclr [_] declr at), oinit, oexpr) -> > return $ CDecl specs [(Just declr, oinit, oexpr)] at > (Just (CPtrDeclr (_:quals) declr at), oinit, oexpr) -> > return $ > CDecl specs [(Just (CPtrDeclr quals declr at), oinit, oexpr)] at This is just an accidental mistake, I suppose ? best regards, benedikt

1 0

other c2hs patches
by John Lato 02 Aug '08

02 Aug '08

Duncan, thanks for all your help recently. I've got another question that depends a bit on the recent patch I submitted. The file Config.hs defines a value for cppopts that is something like "-x c", varying on the platform. If cpp is called using runProcess, then (at least on Windows), those need to be passed as separate arguments (i.e. ["-x", "c"]) in order for cpp to understand them. Although it's a pretty simple change, is this true for other platforms (e.g. Linux) as well? Thanks, John

1 0

available.h on Mac (bug #6)
by John Lato 24 Jul '08

24 Jul '08

Hello, I recently ran up against bug #6 on a Mac (Leopard 10.5.2, c2hs .15.1). This results in the error c2hs: Error in C header file. /usr/include/available.h:85: (column 5) [FATAL] >>> Lexical error! The character '#' does not fit here. I added some information to the bug report based on my experimentation, and would like to say that I've found a workaround. By running c2hs with these options: --cpp=gcc --cppopts=-E --cppopts=-xc I was able to successfully build the interface. This works with cabal builds as well by passing the options during configure with --c2hs-options. I'm pretty certain that this is due to some sort of failure in Apple's cpp and not a problem with c2hs. Can anyone else confirm this? Cheers, John Lato

2 2

Re: [C2hs] distributing packages that use C2HS
by Duncan Coutts 24 Jun '08

24 Jun '08

On Mon, 2008-06-23 at 12:51 -0500, John Lato wrote: > Okay, thanks. I'll just need to live with the dependency on c2hs for > end-users. I suppose if that's a problem, I should have chosen > something other than c2hs as a build tool. In general though it does need to be done on the end users machine so it's not just a c2hs limitation. You may be lucky and know for certain that for the particular C API that you are binding that it is the same on every platform and contains no sizes or offsets of types (since sizes and offsets change between platforms, especially between 32 and 64bit ones). In that happy circumstance then it would be safe to bundle pre-generated .hs files. Cabal will not help you there however since it takes the conservative position that the result of c2hs (and hsc2hs and other FFI pre-processors) is platform dependent. One way to check if its portable is to look at the .hs files generated by c2hs and see if there are any numbers generated. If so then it is platform dependent. Another way of saying it is that call and fun hooks are ok but sizeof, get and set hooks are not. However even if there are no numbers in the generated .hs that doesn't guarantee you're safe. If you're binding to a .h file that might be different on different systems then you've got problems. It is quite common for lots of system headers to use slightly different types on different systems. If you're binding to a C library that has the same implementation on each system or is otherwise guaranteed to have the same C interface then you'd be ok. If you were *absolutely* sure then you could manually include the generated .hs files in dist/build/ in the same path in the tarball and it would work without c2hs installed (assuming you also removed the c2hs build-tool dep). For example see the tarball for happy and where the pre-generated .hs file lives in the tarball (of course for happy, cabal does this automatically because it knows the output of happy is platform independent). Duncan

2 1

distributing packages that use C2HS
by John Lato 23 Jun '08

23 Jun '08

Hello, I have a package (binding to a C library) that uses C2HS that I'm cleaning up for a hackage release. I was wondering if there are any guidelines as to which files to include and how to set up the build. I could include the .chs file, but then anyone trying to build the library would need C2HS. Alternatively, I could include just the .hs file I get from running C2HS (and C2HS.hs), which would be okay, but I would like to provide all available source files for anyone who's interested. Including both seems like asking for trouble in the build process. Does anyone have any recommendations for this? I couldn't find anything addressing it in the cabal packaging guidelines. Thanks, John Lato

3 2

patch applied (c2hs): Bump version number
by Duncan Coutts 21 Jun '08

21 Jun '08

Fri Jun 20 15:39:20 PDT 2008 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Bump version number Just so it's different from the last released version M ./c2hs.cabal -1 +1 View patch online: http://darcs.haskell.org/c2hs/_darcs/patches/20080620223920-9561d-ba0eecb3b…

1 0

patch applied (c2hs): Partially convert to haddock style documentation markup
by Duncan Coutts 21 Jun '08

21 Jun '08

Fri Jun 20 15:34:45 PDT 2008 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Partially convert to haddock style documentation markup M ./src/C2HS/C.hs -3 +3 M ./src/C2HS/C/AST.hs -23 +23 M ./src/C2HS/C/Attrs.hs -28 +27 M ./src/C2HS/C/Builtin.hs -1 +1 M ./src/C2HS/C/Info.hs -7 +7 M ./src/C2HS/C/Names.hs -7 +7 M ./src/C2HS/C/Parser.y -5 +5 M ./src/C2HS/C/Pretty.hs -7 +7 M ./src/C2HS/C/Tokens.hs -2 +2 M ./src/C2HS/C/Trav.hs -89 +85 M ./src/C2HS/CHS.hs -35 +35 M ./src/C2HS/CHS/Lexer.hs -27 +25 M ./src/C2HS/Config.hs -15 +15 M ./src/C2HS/Gen/Bind.hs -66 +66 M ./src/C2HS/Gen/Header.hs -14 +14 M ./src/C2HS/Gen/Monad.hs -29 +29 M ./src/C2HS/State.hs -7 +7 M ./src/C2HS/Switches.hs -4 +4 M ./src/Control/State.hs -30 +28 M ./src/Control/StateBase.hs -12 +11 M ./src/Control/StateTrans.hs -34 +33 M ./src/Data/Attributes.hs -39 +38 M ./src/Data/DLists.hs -9 +9 M ./src/Data/Errors.hs -20 +20 M ./src/Data/Idents.hs -14 +14 M ./src/Data/NameSpaces.hs -8 +8 M ./src/Data/Position.hs -11 +10 M ./src/Data/UNames.hs -8 +8 M ./src/Main.hs -47 +46 M ./src/Text/Lexers.hs -35 +34 View patch online: http://darcs.haskell.org/c2hs/_darcs/patches/20080620223445-9561d-c1196f59d…

1 0

patch applied (c2hs): White space changes
by Duncan Coutts 21 Jun '08

21 Jun '08

Fri Jun 20 12:18:27 PDT 2008 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * White space changes Convert tabs to spaces and remove trailing space M ./src/C2HS/C.hs -76 +76 M ./src/C2HS/C/AST.hs -242 +242 M ./src/C2HS/C/Attrs.hs -86 +86 M ./src/C2HS/C/Info.hs -21 +21 M ./src/C2HS/C/Lexer.x -148 +148 M ./src/C2HS/C/Names.hs -43 +43 M ./src/C2HS/C/Parser.y -539 +539 M ./src/C2HS/C/ParserMonad.hs -13 +13 M ./src/C2HS/C/Tokens.hs -126 +126 M ./src/C2HS/C/Trav.hs -182 +182 M ./src/C2HS/CHS.hs -422 +422 M ./src/C2HS/CHS/Lexer.hs -230 +230 M ./src/C2HS/Config.hs -14 +14 M ./src/C2HS/Gen/Bind.hs -722 +722 M ./src/C2HS/Gen/Header.hs -73 +73 M ./src/C2HS/Gen/Monad.hs -115 +115 M ./src/C2HS/State.hs -17 +17 M ./src/C2HS/Switches.hs -32 +32 M ./src/C2HS/Version.hs -5 +5 M ./src/C2HS/config.c -11 +11 M ./src/C2HS/config.h -4 +4 M ./src/Control/State.hs -86 +86 M ./src/Control/StateBase.hs -13 +13 M ./src/Control/StateTrans.hs -82 +82 M ./src/Data/Attributes.hs -78 +77 M ./src/Data/Errors.hs -28 +28 M ./src/Data/Idents.hs -15 +15 M ./src/Data/NameSpaces.hs -21 +21 M ./src/Data/Position.hs -8 +8 M ./src/Data/UNames.hs -14 +14 M ./src/Main.hs -157 +157 M ./src/System/CIO.hs -22 +22 M ./src/Text/Lexers.hs -111 +111 View patch online: http://darcs.haskell.org/c2hs/_darcs/patches/20080620191827-9561d-d273a0a2d…

1 0