[Forwarded by list administrator.]
-------- Forwarded Message --------
From: Axel Simon
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.
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. Axel.