On Fri, 2015-02-20 at 19:33 +0100, Keri Harris wrote:
I'm writing a language binding using gobject-introspection and have noticed some unexpected behaviour when extracting GByteArray element type information from typelib files. When multiple functions with GByteArray arguments share similar argument names it appears that the first such function appearing in the GIR file determines the element type for all other such functions. As an example, consider the following:
*snip the helpful example*
This behaviour seems restricted to GByteArray types; other array types return the correct element type.
Indeed, it doesn’t affect GArray.
It seems odd to me to specify anything other than a guint8 element type for GByteArray args, but this unexpected behaviour was picked up when extending some of the GByteArray test cases in the gimarshallingtest.c file. At the moment the GByteArray functions in the GIMarshallingTests-1.0.typelib file all use guint8 element types by virtue of the gi_marshalling_tests_bytearray_full_return() appearing first in the GIR file. Adding a gi_marshalling_tests_bytearray_full_in() test case based on gi_marshalling_tests_bytearray_none_in() is enough to cause all GByteArray functions in the marshalling test typelib all use gint8 element types.
Examining the generated typelibs, it looks like the type blob for the two parameters is aliased. Changing the name of one of the functions’ parameters results in the typelib growing and the types being recorded correctly. The GIR file looks fine, so it’s something in the GIR reader or typelib writer. Would you mind filing a bug against gobject-introspection please so someone can investigate further? https://bugzilla.gnome.org/enter_bug.cgi?product=gobject-introspection Philip
Attachment:
signature.asc
Description: This is a digitally signed message part