- C2hs - Haskell.org

#33: The symbol `*' does not fit here
by c2hs 18 Sep '10

18 Sep '10

#33: The symbol `*' does not fit here --------------------+------------------------------------------------------- Reporter: guest | Type: defect Status: new | Priority: normal Milestone: | Component: general Version: 0.16.2 | Keywords: --------------------+------------------------------------------------------- c2hs: C header contains errors: /usr/include/cddb/cddb_cmd.h:79: (column 27) [ERROR] >>> Syntax error ! The symbol `*' does not fit here. -- Ticket URL: <http://hackage.haskell.org/trac/c2hs/ticket/33> c2hs <http://www.cse.unsw.edu.au/~chak/haskell/c2hs/> C->Haskell, An Interface Generator for Haskell

1 2

#32: #get generated code doesn't work on bitfields
by c2hs 26 Aug '10

26 Aug '10

#32: #get generated code doesn't work on bitfields --------------------+------------------------------------------------------- Reporter: guest | Type: defect Status: new | Priority: normal Milestone: | Component: general Version: 0.16.2 | Keywords: --------------------+------------------------------------------------------- Consider the following source files: {{{ /* bitfield.c */ #include "bitfield.h" static testStruct makeItFrom; testStruct* makeIt() { makeItFrom.a = 0; makeItFrom.b = 1; return &makeItFrom; } }}} {{{ /* bitfield.h */ typedef struct testStruct_ testStruct; struct testStruct_ { unsigned a : 31; unsigned b : 1; }; testStruct* makeIt(); }}} {{{ {-# LANGUAGE ForeignFunctionInterface #-} #include "bitfield.h" import C2HS {#pointer *testStruct as TestStructPtr #} main = do x <- {#call makeIt #} print =<< ({#get testStruct->b #} x) }}} Compile as follows: {{{ ezyang@javelin:~/Dev/haskell/c2hs-bitfield$ gcc -c -o bitfield.o bitfield.c ezyang@javelin:~/Dev/haskell/c2hs-bitfield$ c2hs Bitfield.chs ezyang@javelin:~/Dev/haskell/c2hs-bitfield$ ghc --make Bitfield.hs bitfield.o [2 of 2] Compiling Main ( Bitfield.hs, Bitfield.o ) Linking Bitfield ... }}} When you run the resulting executable, the expected output is 1, but the actual output is 0. Looking at the generated HS: {{{ main = do x <- makeIt {-# LINE 10 "Bitfield.chs" #-} print =<< ((\ptr -> do {val <- peekByteOff ptr 4 ::IO CUInt{-:1-}; return $ (val `shiftL` (32 - 1)) `shiftR` (32 - 1)}) x) }}} The byte offset is obviously bogus (the important information must be in offsets 0, 1, 2 or 3). Less obvious is what the correct behavior in all cases is: the bitfield arrangement appears to be compiler dependent. Maybe C2HS should just bug out and say that bitfields are not supported. -- Ticket URL: <http://hackage.haskell.org/trac/c2hs/ticket/32> c2hs <http://www.cse.unsw.edu.au/~chak/haskell/c2hs/> C->Haskell, An Interface Generator for Haskell

1 0

darcs patch: Work-around Language.C's inability to handle CRLF newl...
by ezyang＠MIT.EDU 22 Jul '10

22 Jul '10

Fri Jul 16 15:46:55 PDT 2010 ezyang(a)mit.edu * Work-around Language.C's inability to handle CRLF newlines.

3 2

Re: darcs patch: automagically support stdcall calling convention when ...
by Duncan Coutts 04 Jul '10

04 Jul '10

On Wed, 2010-06-30 at 01:08 -0500, Jonathan Rockway wrote: > * On Mon, Jun 14 2010, Duncan Coutts wrote: > > I've got a follow-on patch, perhaps you could review it? > > Hey Duncan, > > I tested this out on my windows app that uses stdcall calling, and it > works quite nicely. I like the changes you made to my original patch > (C_Call was quite a messy name :). Ok, great. > Also, I got to the bottom of my issue where my header files fail to > parse. The problem is that the line endings on Windows are \r\n, and \r > confuses the parser deeply. It worked in GHC 6.10 because it was being > "smart" about reading the files, but GHC 6.12 changes that behavior. I > poked around in Language.C.Data.InputStream, but didn't find an obvious > place to call hSetNewlineMode, so instead, I just changed the definition > of readInputStream to: > > readInputStream f = liftM (BS.filter (/= '\r')) $ BS.readFile f > > This makes everything work again, but is slightly inelegant. Anyway, > the problem is in Language.C, not C2HS. Yes, this is an "unplanned change" in ghc that affects bytestring text I/O, which Language.C depends on. We're probably not going to be able to change the bytestring behaviour back again and just have to redefine the intended behaviour to the current behaviour. So we'll have to add a fix in Language.C, probably in the lexer where it detects the end of line. > > I believe that one can specify attributes after a C function > > declaration: > > > > void foo() __attribute__((__stdcall__)); > > > > as well as before with the syntax > > > > void __attribute__((__stdcall__)) foo(); > > > > > > This patch looks at the attributes in both positions. > > Seems sane to me, but I haven't seen the first form before. But I am no > expert, I had no idea there were calling conventions until I started > writing this binding on Windows :) Yeah, annoying :-( > I just reverse-engineered my header files (or rather, the result of > running cpp on them) and hacked stuff until c2hs worked ;) :-) > Anyway, thanks for continuing to maintain C2HS. I like the way it works > and it has made my life easier. I owe you a beer sometime :) :-) Duncan

1 0

Re: [c2hs] #29: C2HS chokes on Mac "^" block notation
by c2hs 16 Jun '10

16 Jun '10

#29: C2HS chokes on Mac "^" block notation --------------------+------------------------------------------------------- Reporter: guest | Type: defect Status: new | Priority: normal Milestone: | Component: general Version: 0.16.0 | Keywords: --------------------+------------------------------------------------------- Comment(by guest): `__BLOCKS__`, I mean. Damn wiki formatting. -- Ticket URL: <http://hackage.haskell.org/trac/c2hs/ticket/29#comment:5> c2hs <http://www.cse.unsw.edu.au/~chak/haskell/c2hs/> C->Haskell, An Interface Generator for Haskell

1 0

Re: [c2hs] #29: C2HS chokes on Mac "^" block notation
by c2hs 16 Jun '10

16 Jun '10

#29: C2HS chokes on Mac "^" block notation --------------------+------------------------------------------------------- Reporter: guest | Type: defect Status: new | Priority: normal Milestone: | Component: general Version: 0.16.0 | Keywords: --------------------+------------------------------------------------------- Comment(by guest): Undefining ``BLOCKS`` doesn't help but undefining ``__BLOCKS__`` does (note the underscores). Regardless, Language.C should probably support the blocks notation, I've filed [http://trac.sivity.net/language_c/ticket/2 Ticket 2] to that effect. -- Ticket URL: <http://hackage.haskell.org/trac/c2hs/ticket/29#comment:4> c2hs <http://www.cse.unsw.edu.au/~chak/haskell/c2hs/> C->Haskell, An Interface Generator for Haskell

1 0

Re: darcs patch: automagically support stdcall calling convention when ...
by Duncan Coutts 15 Jun '10

15 Jun '10

On Mon, 2010-06-14 at 04:07 -0500, Jonathan Rockway wrote: > 1 patch for repository http://code.haskell.org/c2hs: > > Mon Jun 14 03:58:17 CDT 2010 Jonathan Rockway <jon(a)jrock.us> > * automagically support stdcall calling convention when the header file specifies it That's great. I've got a follow-on patch, perhaps you could review it? I believe that one can specify attributes after a C function declaration: void foo() __attribute__((__stdcall__)); as well as before with the syntax void __attribute__((__stdcall__)) foo(); This patch looks at the attributes in both positions. Duncan

1 0

Re: [c2hs] #17: c2hs assumes ccall when it should automagically support stdcall for ffi imports
by c2hs 10 Jun '10

10 Jun '10

#17: c2hs assumes ccall when it should automagically support stdcall for ffi imports --------------------+------------------------------------------------------- Reporter: guest | Type: defect Status: new | Priority: normal Milestone: | Component: general Version: 0.15.1 | Keywords: --------------------+------------------------------------------------------- Comment(by guest): Replying to [comment:2 duncan]: > Should be doable now that language-c parses the __attribute__'s Hey guys, I wrote a patch for this a while ago: http://github.com/jrockway/c2hs/commit/a3ac24e1c7d3f2ec542364643f4346caba1a… Supports the stdcall attributes for Windows swimmingly. And ccall still works too. --JonathanRockway (jon(a)jrock.us or jrockway on #haskell) -- Ticket URL: <http://hackage.haskell.org/trac/c2hs/ticket/17#comment:3> c2hs <http://www.cse.unsw.edu.au/~chak/haskell/c2hs/> C->Haskell, An Interface Generator for Haskell

1 0

patch applied (c2hs): Deprecate unused functions in the C2HS source module
by duncan＠community.haskell.org 08 Jun '10

08 Jun '10

Mon Jun 7 20:31:44 EDT 2010 Duncan Coutts <duncan(a)haskell.org> * Deprecate unused functions in the C2HS source module Ignore-this: 97a58b35219b3235cf4bccd11c49fc3e It should not be a general provider of utility functions. It should just be for marshaling functions that are needed by code generated by c2hs. M ./C2HS.hs -32 +50 View patch online: http://code.haskell.org/cgi-bin/darcsweb.cgi?r=c2hs;a=darcs_commitdiff;h=20…

1 0

patch applied (c2hs): Generate standard marshalers for int, float and bool
by duncan＠community.haskell.org 08 Jun '10

08 Jun '10

Mon Jun 7 20:07:41 EDT 2010 Duncan Coutts <duncan(a)haskell.org> * Generate standard marshalers for int, float and bool Ignore-this: 302d7c98b3de571ed8f795c6272f9db8 Rather than non-stanard aliases from the annoying C2HS module. M ./src/C2HS/Gen/Bind.hs -9 +13 View patch online: http://code.haskell.org/cgi-bin/darcsweb.cgi?r=c2hs;a=darcs_commitdiff;h=20…

1 0