<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-12-17 13:41 GMT+01:00 Henning Thielemann <span dir="ltr"><<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On Sun, 17 Dec 2017, Merijn Verstraaten wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br>
But that's tailored to C. If I understand Sven correctly, then this is not valid for Storable.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div>