Re: Defining a libffi.so.4 ABI

[Dan Witte <dwitte at mozilla dot com>]

If we're defining a new API as part of this change, there are a few things we could improve:

* Add an exported API for initialize_aggregate, and add offset information for FFI_TYPE_STRUCTs, so that consumers can get information about structs without having to calculate offsets themselves or abuse ffi_prep_cif.

* Add FFI_TYPE_ARRAY support. This can currently be done by abusing FFI_TYPE_STRUCT, but if one has a 4GB array of bytes, it's really going to suck. Implementing this should involve the same codepaths as FFI_TYPE_STRUCT, with special cases that look like a repeated field.

* Have ffi_call return an ffi_status value, indicating whether an incorrect number of args were supplied. This obviously only makes sense for calling conventions where the callee cleans the stack, such as stdcall. Other conventions could always return FFI_OK. Due to this inconsistency, this might not be a good idea.

Should we decide now that we're breaking compat for the next release, and call it libffi-4.0.0? And, are there any other suggestions for improvements?

Regards,
Dan.


----- "Rainer Orth" <ro@CeBiTec.Uni-Bielefeld.DE> wrote:

> I've posted the message below to the gcc@gcc.gnu.org, but got no
> response other than pointing out to me that posting to libffi-discuss
> might be helpful.
> 
> So here we go.  Please keep me on the Cc: since I'm not subscribed to
> libffi-discuss.
> 
>         Rainer
> 
> 
> 
> 
> 
> -- 
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University