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

[Manuel M T Chakravarty]

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: c2hs_config.c
Type: text/x-csrc
Size: 3061 bytes
Desc: not available
Url : http://www.haskell.org//pipermail/c2hs/attachments/20050807/88865976/c2hs_config.bin