C2hs

Download

c2hs@haskell.org

January 2006

1 participants
2 discussions

making c2hs undrstand line pragmas
by Duncan Coutts 24 May '06

24 May '06

Manuel, I've got a patch to c2hs to make it do something with C style line pragmas in .chs files, eg: # 1 "gtk/Graphics/UI/Gtk/TreeList/TreeStore.chs.pp" These are produced by the C preprocessor. Currently c2hs chokes on these and so people have to use the -P option to cpp to suppress them. They are actually rather useful if the code in fact does need preprocessing (as most of gtk2hs's .chs files do) because they point to the original file name and source locations. For example it means that ghc's errors will report accurate locations in the .chs.pp file rather than reporting locations in the .chs file. c2hs already produces accurate Haskell line pragmas {-# LINE ... #-} in the .hs files it produces for exactly that reason. I want to extend that to the case that the .chs file itself has had a preprocessor used on it. One other reason to preserve the original file name is that haddock can now include links to the source files, and it uses the line pragmas to find the original source file. It doesn't do much good however if haddock links to a non-existant .chs file when the real original file was .chs.pp. So here's an example; the Gtk2Hs docs with source code links to our darcs repository: http://haskell.org/gtk2hs/docs/devel/ For example the link at the top of this page: http://haskell.org/gtk2hs/docs/devel/Graphics-UI-Gtk-Abstract-Widget.html points to: http://darcs.haskell.org/gtk2hs/gtk/Graphics/UI/Gtk/Abstract/Widget.chs.pp which is right. Of course, without the patch it'd point to the non-existant file Widget.chs. The way my patch works is to make the lexer recognise the line directives and update the current position. However to get the line directives emitted correctly we also have to insert a special token into the token stream. When it comes to finally printing the token stream, this special token puts the printer into a state in which it will add a Haskell {-# LINE ... #-} pragma before the next Haskell source fragment. The only thing that's wrong is that c2hs doesn't recognise cpp directives as the first line in a .chs file. You can see why this is so from the code below: cpp :: CHSLexer cpp = directive where directive = string "\n#" +> alt ('\t':inlineSet)`star` epsilon `lexmeta` \(_:_:dir) pos s -> -- strip off the "\n#" case dir of ... etc It's requires a cpp directive to start with a newline followed by a '#' character. I'm not sufficiently familiar with the style of c2hs's chs lexer to figure out how to fix this. Perhaps it can be done by checking if we're at the beginning of a line in a different way. Perhaps it can be done by checking the current column rather than looking for a '\n' character. -------------- So in summary: Manuel, so if you don't complain about how this change works I'll commit it in the next few days. And my my question is how to fix this issue with recognising cpp directives on the first line. Duncan

2 2

sizeof hook calculates the wrong size
by Volker Wysk 24 May '06

24 May '06

Hello The sizeof hook calculates the size wrong in this example: ----------------------------------------------------------------- main = putStrLn (show {# sizeof loop_info64_t #}) #c #include <linux/loop.h> typedef struct loop_info64 loop_info64_t; #endc ----------------------------------------------------------------- Translated to: ----------------------------------------------------------------- ... {-# LINE 1 "bug.chs" #-}main = putStrLn (show 72) ----------------------------------------------------------------- The structure is much larger. loop_info64 is defined in /usr/include/linux/loop.h like this: ----------------------------------------------------------------- struct loop_info64 { __u64 lo_device; /* ioctl r/o */ __u64 lo_inode; /* ioctl r/o */ __u64 lo_rdevice; /* ioctl r/o */ __u64 lo_offset; __u64 lo_sizelimit;/* bytes, 0 == max available */ __u32 lo_number; /* ioctl r/o */ __u32 lo_encrypt_type; __u32 lo_encrypt_key_size; /* ioctl w/o */ __u32 lo_flags; /* ioctl r/o */ __u8 lo_file_name[LO_NAME_SIZE]; __u8 lo_crypt_name[LO_NAME_SIZE]; __u8 lo_encrypt_key[LO_KEY_SIZE]; /* ioctl w/o */ __u64 lo_init[2]; }; ----------------------------------------------------------------- It looks like the the arrays are mistaken for pointers. There's another small bug. If you reorder main and the C block in the example above, such that "#c" is the first line, then you get a parse error. -- public key fingerprint: 6A10 66F1 40A2 C441 BB55 0AA8 FAB1 4FC1 08BE 24EF

2 1