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

[Yuras Shumovich]

Hi,

I thought I have lost the battle :)
Thank you for the support, Simon!

I'm interested in full featured solution: arguments, return value,
foreign import, foreign export, etc. But it is too much for me to do it
all at once. So I started with dynamic wrapper.

The plan is to support structs as arguments and return value for dynamic
wrapper using libffi;
then implement native adjustors at least for x86_64 linux;
then make final design decision (tuple or data? language pragma? union
support? etc);
and only then start working on foreign import. 

But I'm open for suggestions. Just let me know if you think it is better
to start with return value support for foreign import. 

Thanks,
Yuras

On Tue, 2014-03-18 at 12:19 +0000, Simon Marlow wrote:
> I'm really keen to have support for returning structs in particular. 
> Passing structs less so, because working around the lack of struct 
> passing isn't nearly as onerous as working around the lack of struct 
> returns.  Returning multiple values from a C function is a real pain 
> without struct returns: you have to either allocate some memory in 
> Haskell or in C, and both methods are needlessly complex and slow. 
> (though allocating in Haskell is usually better.) C++ code does this all 
> the time, so if you're wrapping C++ code for calling from Haskell, the 
> lack of multiple returns bites a lot.
> 
> In fact implementing this is on my todo list, I'm really glad to see 
> someone else is planning to do it :-)
> 
> The vague plan I had in my head was to allow the return value of a 
> foreign import to be a tuple containing marshallable types, which would 
> map to the appropriate return convention for a struct on the current 
> platform.  Perhaps allowing it to be an arbitrary single-constructor 
> type is better, because it allows us to use a type that has a Storable 
> instance.
> 
> Cheers,
> Simon
>