-------- Forwarded Message -------- From: Axel Simon To: c2hs@haskell.org, Gtk2Hs-devel List Subject: Re: [Gtk2hs-devel] hsffig & c2hs Date: Wed, 03 Aug 2005 10:18:43 +0100 On Wed, 2005-08-03 at 00:26 +0100, Duncan Coutts wrote:

...

It might be interesting to see if we can use c2hs completely rather than hsc2hs in places. c2hs development has picked up recently (yes, partly due to moving to darcs) so if there are any lurking offset/sizeof bugs I'm sure we can get them fixed.

I don't think there there are any more bugs in c2hs as such. The main problem is building on windows, where Gtk+ is built with Visual-C-style bitfields and padding of structs. The reason I used hsc2hs is that I can explicitly pass the -mms-bitfields flag to hsc2hs on Windows which ensures that the header files are interpreted in Microsoft-style. Note that using -mms-bitfields is not a Microsoft thing, it's a compiler issue. At configure time, c2hs checks the platform to decide how fields are laid out, but, in fact, the layout depends on how the library was compiled. So to use c2hs we need to add a flag to c2hs that tells it to use Visual-C struct layout rather than gcc-style layout.

I think, this should be easy to solve fairly soon. The next feature that I want to add to c2hs is support for cross compilation. (Tony Sloane needs this to produces bindings for Palm OS.) My plan is this: * By default, c2hs will use the conventions re bitfields as those of the C compiler used to compile the .c files in c2hs' source tree. * There will be a command line option that permits to override that choice and to explicitly specify the platform for which bindings are generated. C2hs will have a database of platforms it knows about and all we need to do is to ensure that Visual-C gets an entry in that database.

...

From the internal gcc docs:

...following the rules of Microsoft Visual C/C++, namely: (i) a bit- field won't share the same storage unit with the previous bit-field if their underlying types have different sizes, and the bit-field will be aligned to the highest alignment of the underlying types of itself and of the previous bit-field; (ii) a zero-sized bit-field will affect the alignment of the whole enclosing structure, even if it is unnamed; except that (iii) a zero-sized bit-field will be disregarded unless it follows another bit-field of nonzero size.

In other words: it's a bit complicated.

All I need is a for somebody to compile and run the attached C functions in Visual C and let me know the results. Will that not solve the issue? Manuel