This is the mail archive of the libffi-discuss@sourceware.org mailing list for the libffi project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: documentation patch, oddities, and proposals


I sent my documentation patch as a PR.

[...]
rth> Indeed.  I've thought about ways to fix this in the past, and the best
rth> I can think of imply an api+abi change.

rth> Basically, stop exporting all of the ffi_type_foo variables (which
rth> themselves imply nasty abi compatibility problems, due to the COPY
rth> relocs they require).

rth> Instead, have a function call taking an enumeration for the basic
rth> types, as well as the abi enum.  Which means that ppc can have two
rth> separate structures for its longdouble, which means that both can be
rth> read-only.

Ok, following up on this, here's my wish-list if an ABI break is
possible.

* Require each ABI to have a string name and provide a way to look up
  ABI by name.

  This would let generic FFI wrappers expose ABIs to their callers
  without undue difficulty.  This would be handy at least for Lisp
  bindings; and it seems reasonably lightweight.

  Also, document all ABIs -- not really an ABI problem, but worth
  pointing out.

  I suppose this could be added without breaking ABI.

* As you said, get rid of ffi_type_* globals, replace with per-ABI calls
  using the FFI_TYPE_* constants.

* Require a separate type-prep stage.  For struct types allow an out
  parameter that would fill in field offsets.  Requiring the separate
  call would make it possible for all the calls taking an ffi_type to be
  const-correct.

* Add FFI_TYPE_UNION and FFI_TYPE_ARRAY.

* Mark each ffi_type with an "ABI-specific" flag.  This would taint a
  type as ABI-specific.  Layout of a struct (or union or array) would
  propagate this flag from the members to the aggregate.  The idea here
  is that in most cases this just doesn't matter and this would give an
  easy way to notice when it does.  ffi_prep_cif could check this flag.


Adding bitfield support might be nice, not sure.

I don't care a whole lot about the ffi_arg thing, but if it isn't
completely crazy to fix it, it might be a good idea.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]