This is only roughly related, but long ago I completely replaced Storable in my own hsc2hs-using code with CStorable, which is a copy of Storable, except having only the instances that I choose. Specifically, it has instances for CChar but not Char, for CBool but not Bool, etc. because it's too dangerous to silently allow these memory-corrupting instances. I think reusing Storable for C serialization was a mistake. Replacing Storable was pretty easy though, just copy-paste the 200-line Foreign module and change the class name. On Sun, Dec 17, 2017 at 11:02 AM, Sven Panne wrote:

2017-12-17 13:41 GMT+01:00 Henning Thielemann :

...

On Sun, 17 Dec 2017, Merijn Verstraaten wrote:

...

Tools like hsc2hs already pad the result of sizeOf to the appropriately aligned size (at least the ones I've used), so this is a non-issue for that scenario.

But that's tailored to C. If I understand Sven correctly, then this is not valid for Storable.

I'm not sure if I understand the concerns about hsc2hs here correctly, but anyway: There are intentionally no Storable instances for struct-like things in the FFI spec, but that doesn't rule out that one can define instances for a special purpose (e.g. native ABI compliant ones) on your own. hsc2hs, c2hs, GreenCard etc. are tools to help you with that (and much more). This doesn't contradict anything in the FFI spec, you just choose one of several possible semantics in your program for types which are not even mentioned in the spec. OTOH, as an author of a general library I would be very hesitant to define such instances, they might not be what the library user expects.

Perhaps we really want to extend the FFI spec in such a way that only one kind of instance makes sense for a given type (including complex ones), e.g. by defining separate classes for the different purposes mentioned in this thread. But this would need some serious design thoughts to get this right and flexible enough while avoiding to break tons of FFI code already out there.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Sun, Dec 17, 2017 at 11:55 PM, Henning Thielemann wrote:

On Sun, 17 Dec 2017, Evan Laforge wrote:

...

This is only roughly related, but long ago I completely replaced Storable in my own hsc2hs-using code with CStorable, which is a copy of Storable, except having only the instances that I choose. Specifically, it has instances for CChar but not Char, for CBool but not Bool, etc. because it's too dangerous to silently allow these memory-corrupting instances. I think reusing Storable for C serialization was a mistake. Replacing Storable was pretty easy though, just copy-paste the 200-line Foreign module and change the class name.

Would you mind moving this class to a public package?

Done, after much delay: http://hackage.haskell.org/package/c-storable-0.2 That said, from the README: If you are writing a new C binding, I recommend something higher-level than hsc2hs, such as c2hs, which I think should sidestep the problem entirely by verifying your types. But if you are already using hsc2hs and for whatever reason don't want subtle memory corruption bugs, you can import ForeignC instead of Foreign and Foreign.C, and see if you have any.

On Wed, Mar 7, 2018 at 11:13 AM, John Wiegley wrote:

...

...

...

...

...

"EL" == Evan Laforge writes:

EL> If you are writing a new C binding, I recommend something higher-level EL> than hsc2hs, such as c2hs, which I think should sidestep the problem EL> entirely by verifying your types. But if you are already using hsc2hs and EL> for whatever reason don't want subtle memory corruption bugs, you can EL> import ForeignC instead of Foreign and Foreign.C, and see if you have any.

Note that c2hsc is even higher, since it will generate the .hsc files for you from the C headers.

So many C FFI tools. Is there a survey somewhere? That might have saved me some time long ago, when it seemed like the only choices were green card and hsc2hs, and green card was already somewhat obsolete looking. But come to think of it, I don't even know why...