[C2hs] Re: [Gtk2hs-devel] hsffig & c2hs

[Manuel M T Chakravarty]

[Forwarded by list administrator.]

-------- Forwarded Message --------
From: Axel Simon <A.Simon at kent.ac.uk>
To: c2hs at haskell.org, Gtk2Hs-devel List <gtk2hs-
devel at lists.sourceforge.net>
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.

>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.