Re: Does a FFI_STRUCT type really need the elements array?

[Anthony Green <green@moxielogic.com>]

Hi Kaz,

There are complexities around dealing with structs with nested struct elements.

It sounds like yours is a special case, where you are doing a lot of
work that is normally done by libffi, which is too bad.

The libffi API is far from perfect, but this is one area where there
have been few complaints.  That being said, it would be interesting to
hear a more fully formed proposal that could be considered prior to a
major API breaking release.

AG


On Wed, Jun 21, 2017 at 10:34 PM, Kaz Kylheku <kaz@kylheku.com> wrote:
> Hi libffi users,
>
> Here is the thing. Suppose I have a sophisticated FFI implementation
> which uses libffi.  Of course I've done all the struct layout calculations
> yourself: the offset of every member, taking into account its alignment to
> generate any padding in between them and at the end. (I need this in
> situations
> not involving libffi!)
>
> Yet, I have to mirror this information in the libffi data structure:
> a FFI_STRUCT type has to have an elements[] array of types. Presumably
> libffi just walks these, redundantly doing the same calculations to get
> the offset of every member, total size with padding and alignment.
>
> Can't we dispense with the elements[] array and just punch in the size
> and alignment values into the struct type (that are supposed to be left
> zero?)
>
> Or is there some compromise: a one-element elements[] array (well two, with
> null termination), where a single element indicates the size and
> alignment somehow.
>
> Or how about a one-element array whose one and only pointer is the
> null terminator; with the size and alignment punched in: would that
> work?
>
> It's wasteful to allocate, initialize and free these arrays and to have
> libffi walking over them.
>
> Any words of wisdom?
>