GNOME Bugzilla – Bug 552371
implement struct field get/set
Last modified: 2015-02-07 17:03:15 UTC
Something like: void g_field_info_get_value(GIFieldInfo *info, GArgument *arg_out); void g_field_info_set_value(GIFieldInfo *info, GArgument *arg); All bindings have to implement GArgument to/from their native types anyway, so these would be pretty convenient.
Bitfields need to be calculated as well. ctypes get this right, their implementation can be found here: http://svn.python.org/view/python/trunk/Modules/_ctypes/cfield.c?rev=66683&view=auto
I have also implemented a struct/union field offset calculator in my Scheme binding for gobject-introspection which supports bitfields and struct/union members as well: http://download.gna.org/spells/darcs/r6rs/sbank/stypes.sls The code in question is implemented by 'calculate-sizes', which in turn calls 'calculate'. Note that sbanks is very young and hence the code is not well-test and may well be buggy.
As the typelib is platform dependent, couldn't we use python ctypes to calculate the offsets at compile time?
(In reply to comment #3) > As the typelib is platform dependent, couldn't we use python ctypes to > calculate the offsets at compile time? > But then the typelib would contain more information than the .gir, is that ok?
Additionally to the struct offsets, we need a "bit offset" for bitfield members, for example: struct { guint tag : 5; guint deprecated: 1; }; Would produce offset=0, bit-offset=0 for "tag" and offset=0 and bit-offset=5 for "deprecated". Of course this presumes that the offset data is calculated at compile-time.
I'm working on some C code for now to go in the compiler to compute field offsets. Ignoring bitfields for now. It uses a little bit of information from libffi - ffi_type_pointer.size/alignment, etc; that logic could be easily be borrowed or duplicated if necessary. Johan - as I understand it, the plan is that .gir is arch-independent while the typelib is arch-dependent and thus can contain offsets.
Having the offsets in the typelib seems more efficient than requiring bindings to walk over fields adding up field sizes, anyway. May as well precompute these values.
Owen: Yes, girs should be platform independent for now. However I think we'll end up with one gir per library in some cases eg a separate one for each gdk backend, (but that's separate from this bug). The typelib can be platform dependent for now as we currently don't have any good reasons for making them work between platforms. Bitfields can go in later, we can worry about that in another bug. Putting the offsets in the typelib should be okay. I haven't thought enough about it, eg ruling out the possibility of calculate it in runtime in some situations.
Created attachment 122662 [details] [review] Add g_field_info_set/get_field() Here's a patch adding a straightforward set/get field. Enums are not implemented in this: I want to add extend the typelib and add g_enum_info_get_storage_type() to keep funky ABI knowledge in the compiler and make it easier for people not using convenience functions. Composite fields like GdkRectangle aren't handled here - I think they will generally need special handling from a language binding, especially for write.
Small typo in the docs for _write_field, Returns: ...reading. What defines G_STRUCT_MEMBER?
Looks good to me.
Fixed up a memory leak of GFieldInfo and GTypeInfo and committed.
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]