FFI: c/c++ struct on stack as an argument or return value

[Edward Kmett]

I don't care enough to fight and try to win the battle, but I just want to
point out that Storable structs are far more brittle and platform dependent
than borrowing the already correct platform logic for struct passing from
libffi.

I do think the existing FFI extension made the right call under the 32 bit
ABIs that were in use at the time it was defined. That said, with 64-bit
ABIs saying that 2 32-bit ints should be passed in a single 64 bit
register, you wind up with large chunks of third party APIs we just can't
call out to directly any more, requiring many one-off manual C shims.

-Edward




On Sat, Mar 15, 2014 at 12:17 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> indeed, its very very easy to do storable instances that correspond to the
> struct type you want,
>
> the ``with`` function in
> http://hackage.haskell.org/package/base-4.6.0.1/docs/Foreign-Marshal-Utils.htmlforeigh.marshal.utils actually gets you most of the way there!
>
>
>
>
> On Sat, Mar 15, 2014 at 12:00 AM, Manuel M T Chakravarty <
> chak at cse.unsw.edu.au> wrote:
>
>> Yuras,
>>
>> I’m not convinced that the compiler is the right place for this kind of
>> functionality. In fact, when we designed the Haskell FFI, we explicit
>> decided against what you propose. There are a few reasons for this.
>>
>> Firstly, compilers are complex beasts, and secondly, it takes a long time
>> until a change in the compiler goes into production. Hence, as a general
>> rule, it is advisable to move complexity from the compiler into libraries
>> as this reduces compiler complexity. Libraries are less complex and changes
>> can be rolled out much more quickly (it’s essentially a Hackage upload
>> versus waiting for the next GHC and Haskell Platform release).
>>
>> Thirdly, we have got the Haskell standard for a reason and modifying the
>> compiler implies a language extension.
>>
>> The design goal for the Haskell FFI was to provide the absolute minimum
>> as part of the language and compiler, and to layer additional conveniences
>> on top of that in the form of libraries and tools.
>>
>> Have you considered the library or tool route?
>>
>> Manuel
>>
>> Yuras Shumovich <shumovichy at gmail.com>:
>> > Hi,
>> >
>> > Right now ghc's FFI doesn't support c/c++ structures.
>> >
>> > Whenever we have foreign function that accepts or returns struct by
>> > value, we have to create wrapper that accepts or returns pointer to
>> > struct. It is inconvenient, but actually not a big deal.
>> >
>> > But there is no easy workaround when you want to export haskell function
>> > to use it with c/c++ API that requires structures to be passed by value
>> > (Usually it is a callback in c/c++ API. You can't change it's signature,
>> > and if it doesn't provide some kind of "void* userdata", then you are
>> > stuck.)
>> >
>> > I'm interested in fixing that. I'm going to start with 'foreign import
>> > "wrapper" ...' stuff.
>> >
>> > Calling conventions for passing c/c++ structures by value are pretty
>> > tricky and platform/compiler specific. So initially I'll use libffi for
>> > that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see
>> > rts/Adjustor.c). It will allow me to explore design space without
>> > bothering about low level implementation details. Later it could be
>> > implemented for native (non-libffi) adjustors.
>> >
>> > Is anybody interested it that? I appreciate any comments/ideas.
>> >
>> > Right now I don't have clear design. It would be nice to support plain
>> > haskell data types that are 1) not recursive, 2) has one constructor and
>> > 3) contains only c/c++ types. But it doesn't work with c/c++ unions. Any
>> > ideas are welcome.
>> >
>> > An example how to use libffi with structures:
>> > http://www.atmark-techno.com/~yashi/libffi.html#Structures
>> >
>> > Thanks,
>> > Yuras
>> >
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140315/4e855161/attachment.html>