Storable laws

[Evan Laforge]

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 <svenpanne at gmail.com> wrote:
> 2017-12-17 13:41 GMT+01:00 Henning Thielemann
> <lemming at henning-thielemann.de>:
>>
>>
>> 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>