April 2007 - C2hs - Haskell.org

patch applied (c2hs): Remove redundancy in the representation of pointer declarators
by Duncan Coutts 25 Apr '07

25 Apr '07

Tue Apr 24 22:29:29 PDT 2007 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Remove redundancy in the representation of pointer declarators It was an artifact of the previous parser that we represented a whole list of pointer type modifiers in one go rather than a single ast constructor for each pointer layer as we do now. This is simpler. M ./c2hs/c/CAST.hs -1 +1 M ./c2hs/c/CParser.y -20 +20 M ./c2hs/c/CPretty.hs -1 +1 M ./c2hs/c/CTrav.hs -5 +2

1 0

patch applied (c2hs): Add a --numeric-version flag, just like ghc has
by Duncan Coutts 25 Apr '07

25 Apr '07

Tue Apr 24 21:42:30 PDT 2007 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Add a --numeric-version flag, just like ghc has Should make it easier for build tools like cabal to check the c2hs version. M ./c2hs/toplevel/Main.hs -8 +14 M ./c2hs/toplevel/Version.hs -1 +1

1 0

patch applied (c2hs): In the common case of #include' ing a single header we don' t need a .chs.h file
by Duncan Coutts 25 Apr '07

25 Apr '07

Tue Apr 24 21:37:20 PDT 2007 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * In the common case of #include'ing a single header we don't need a .chs.h file So say if you do: ch2s foo.h foo.chs and you don't add any other includes in the .chs file then it's kind of annoying to have to generate this tiny .chs.h file that just contains #include "foo.h" we could instead make the ffi imports in the .hs file refer directly to foo.h rather than indirectly via foo.chs.h. Annoyingly we still have to actualy generate foo.chs.h to pass to cpp to get foo.chs.i, but we can delete foo.chs.h immediately after so the user never sees it. M ./c2hs/toplevel/Main.hs -3 +16

1 0

patch applied (c2hs): Allow any number of .h files to be passed on the command line
by Duncan Coutts 25 Apr '07

25 Apr '07

Tue Apr 24 21:33:40 PDT 2007 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Allow any number of .h files to be passed on the command line They'll all be added to the generated .chs.h file. This will allow cabal to pass all the .h files listed in the .cabal file. M ./c2hs/toplevel/Main.hs -28 +27

1 0

patch applied (c2hs): Use .chs.h suffix for generated header files
by Duncan Coutts 25 Apr '07

25 Apr '07

Tue Apr 24 21:30:49 PDT 2007 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Use .chs.h suffix for generated header files Hopefully this will not clash with user's own .h files. M ./c2hs/toplevel/Main.hs -1 +1

1 0

Re: [Haskell-cafe] Re: [C2hs] anyone interested in developing a Language.C library?
by Duncan Coutts 21 Apr '07

21 Apr '07

On Sat, 2007-04-21 at 12:04 +0200, Josef Svenningsson wrote: > Unfortunately the niche is not empty. There is an ocaml library called > cil which is supposed to be pretty sweet for manipulating C code. But > I still think a Haskell library would be a very good idea, and perhaps > one can look at cil for inspiration. > > cil can be found here: > http://hal.cs.berkeley.edu/cil/ Yeah, I came across this recently. It's pretty decent looking. I briefly looked at their C parser (also implemented as a lex/yacc style lexer & parser). Theirs also covers Sun and MS C language extensions, that is Sun CC's pragmas and MS's numerous extensions. Sadly this didn't popup when I was googling for yacc style LALR(1) C grammars or I might have saved myself some time by porting their grammar to alex+happy. Duncan

1 0

anyone interested in developing a Language.C library?
by Duncan Coutts 20 Apr '07

20 Apr '07

Hi all, If anyone is interested in developing a Language.C library, I've just completed a full C parser which we're using in c2hs. It covers all of C99 and all of the GNU C extensions that I have found used in practise, including the __attribute__ annotations. It can successfully parse the whole Linux kernel and all of the C files in all the system packages on my Gentoo installation. It's implemented as an alex lexer and a happy parser. The happy grammar has one shift/reduce conflict for the dangling if/then/else issue (which could be hidden by using precedence but it's clearer not to). So if someone is interested in developing a more widely usable Language.C library, I think this would be a good place to start. There's plenty to do however: * The c2hs C AST is ok but probably not enough for a general purpose library. * The parser currently uses some other c2hs infrastructure which would need disentangling to pull the parser out (mostly identifiers and unique name supply management). * It does not record everything into the parse tree, eg __attribute__s are parsed but ignored. * It does no semantic analysis after parsing (though other bits of c2hs to a very little) * In at least one place the parser is deliberately too liberal (to avoid ambiguities) which would require simple extra checks after parsing to detect. * The lexical syntax has not been checked against the spec fully, it is probably over-liberal in some cases. * I've not done much performance work, the lexer has not been seriously tuned, it still lexes via a String. Having said that, the performance is not at all bad, on a 3Ghz box it does ~20k lines/sec. * The parser error messages are terrible (it might be interesting to try porting from happy to frown for this purpose) There's probably more stuff, but that's what I can think of right now. So if anyone is interested then let me know, I can give some pointers (hopefully the useful kind, not the void * kind). You can get the code from the c2hs darcs repo: darcs get --partial http://darcs.haskell.org/c2hs/ The C parser bits are under c2hs/c/ Duncan Licensing: It's not 100% clear. At the moment it's marked as GPL, but it's derived from several sources so we need to be careful about that. Personally I'm happy to use LGPL. It derives from c2hs obviously, which is GPL, though we could enquire about re-licencing, especially since there is very little of c2hs stuff used in it any more. It also derives partly from James A. Roskind's C grammar (in particular the grammar of declarations). His copyright license is fairly liberal but this need double-checking. It also derives from the C99 spec and I read the comments in the gcc C parser as a guide to GNU C's extensions to the C grammar (no code or comments were copied however). Testing: I tested it thus far by writing a little gcc wrapper script, so you can build any ordinary bit of C software using this wrapper and it'll call gcc with the same args but it'll also try and parse the input file. It reports into a log file. I've not tried the gcc C parser testsuite. This approach is probably good for other tests like trying to see if parsing and pretty printing can round-trip correctly; if not identical token streams (since parsing drops redundant brackets etc) checking if gcc produces identical .S/.o files. Something that c2hs needs is to calculate sizes of types and structure member offsets correctly. This is also something that could be tested in this style, by comparing on thousands of example .c files with what gcc thinks.

2 1

patch applied (c2hs): Make the cc-wrapper program work without needing any hacking
by Duncan Coutts 20 Apr '07

20 Apr '07

Thu Apr 19 22:59:49 PDT 2007 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Make the cc-wrapper program work without needing any hacking M ./c2hs/c/tests/CCWrapper.hs -21 +21

1 0

patch applied (c2hs): Put myself as primary author and update docs
by Duncan Coutts 20 Apr '07

20 Apr '07

Thu Apr 19 22:54:52 PDT 2007 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Put myself as primary author and update docs I've rewritten it twice so should probably list myself as main author. It is of course derived from Manuel Chakravarty's original c2hs C parser and from James A. Roskind's C grammar and the copyright notices reflect that. We need to double check Mr Roskind's copyright license to make sure we're respecting it properly. Also remove some docs that don't really apply anymore and add a couple TODOs. M ./c2hs/c/CParser.y -33 +9

1 0

RE: darcs patch: added cppOptions and c2hsOptions
by Vivian McPhail 20 Apr '07

20 Apr '07

Hi Duncan, I added cppOptions because in the Cabal.cabal file there was a comment to add cppOptions and so I did it. With respect to c2hsOptions, the problem is that c2hs passes options to the CPP nonstandardly (with --cppopts=), so even if I have an -I* option in my ccOptions that gets passed to c2hs, this works for c2hs, but doesn't get passed to the cpp that c2hs uses. I've sent a message to the c2hs/cabal mailing list with a dummy package that recreates all the problems I had on mingw/WinXP. The reason the c files are outside the Cabal hierarchy is that they are supposed to mimic libs/headers that are already on the system and would (normally) be found with an autoconf script. I think it would be a great idea to change the name of the .h file that c2hs generates. It would make naming Haskell sources/modules more consistent with their targets. Cheers, Vivian > -----Original Message----- > From: Duncan Coutts [mailto:duncan.coutts@worc.ox.ac.uk] > Sent: Wednesday, 18 April 2007 3:31 p.m. > To: Vivian McPhail > Cc: cabal-devel(a)haskell.org > Subject: Re: darcs patch: added cppOptions and c2hsOptions > > On Wed, 2007-04-04 at 03:33 +1200, Vivian McPhail wrote: > > > Wed Apr 4 03:32:49 New Zealand Standard Time 2007 Vivian McPhail > > <omconsult(a)gmail.com> > > * added cppOptions and c2hsOptions > > Hia Vivian, > > Can you explain to me again exactly why we need these extra options? > As I see it, cpp options can just be included in the cc options, is > there any need to separate them? > > Cabal currently looks for -D* -U* and -I* flags in the cc options and > passes them to c2hs. Are there any other ones that we are missing > there? > It's quite convenient for users not to have to separate the cc flags > into cpp ones, since many other tools intermingle them (off the top of > my head I can think of pkg-config). > > As for the c2hs options, again I'm not clear as to why this is > necessary. c2hs doesn't support that many interesting flags: > > -C CPPOPTS --cppopts=CPPOPTS pass CPPOPTS to the C preprocessor > -c CPP --cpp=CPP use executable CPP to > invoke C preprocessor > -d TYPE --dump=TYPE dump internal information > (for debugging) > -h, -? --help brief help (the present message) > -i INCLUDE --include=INCLUDE include paths for .chi files > -k --keep keep pre-processed C header > -l --copy-library copy `C2HS' library module in > -o FILE --output=FILE output result to FILE > (should end in .hs) > -p PLATFORM --platform=PLATFORM platform to use for cross > compilation > -t PATH --output-dir=PATH place generated files in PATH > -v --version show version information > > I think all of these are either not useful or can be selected > automatically. > > As for the optional .h file that can be passed on the command line, > the better way to do that is to put the #include inside the .chs file. > > The alternative is to extend c2hs to accept many .h files on the > command line and we can pass all the files in the 'includes:' field to > c2hs. I'm considering extending c2hs to allow this. I'm also planning > to change c2hs so that the .h file it generates will not clash with > anything else, for foo.chs it'll generate foo.chs.h and possibly > foo.chs.c too. > > Is there anything I've missed? > > Duncan >

1 0