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