Re: Marshaling (inout) structs/objects

[Iñaki García Etxebarria <garetxe gmail com>]

Hi,

Thanks for the replies, Philip and Jasper!

I tried pango_matrix_transform_pixel_rectangle in Python, and it segfaults:
====
In [1]: from gi.repository import Pango
/usr/bin/ipython:1: PyGIWarning: Pango was imported without specifying a version
first. Use gi.require_version('Pango', '1.0') before import to ensure that the
right version gets loaded.
  #!/usr/bin/python2

In [2]: m = Pango.Matrix()

In [3]: r = Pango.Rectangle()

In [4]: m.transform_pixel_rectangle(r)
/usr/bin/ipython:1: Warning: g_variant_ref: assertion 'value->ref_count > 0'
failed
  #!/usr/bin/python2
[1]    18762 segmentation fault (core dumped)  ipython
====

This, together with the fact that the JS bindings complain about boxing and
ownership transfer (why would they if they used interpretation (a), i.e. the
contents being mutated?) leads me to think that interpretation (b) is probably
what the Python and JS bindings chose, same as Haskell is doing currently. Is
this correct? I will file some bugs with the relevant libraries to remove the
erroneous (inout) annotation if so.

And perhaps a line could be added to
https://wiki.gnome.org/action/show/Projects/GObjectIntrospection/Annotations
documenting this point?

Cheers,
Iñaki

On Thu, 2016-10-27 at 04:41 +0000, philip chimento gmail com wrote:
> On Wed, Oct 26, 2016 at 12:24 PM Iñaki García Etxebarria <garetxe gmail com>
> wrote:
>
> > Hi,
> >
> > In writing the Haskell bindings for gobject-introspection I ran into some
> > apparent ambiguity, and I cannot find a discussion of this point in the
> > gobject-introspection annotation specs, so I wanted to ask what other
> > languages
> > are doing/what is best practice.
> >
> > For simple scalar types, such as gint, it is clear that (inout) means that
> > the
> > argument of the function is of type "gint*", and that the value pointed to
> > by
> > the argument may be overwritten by the callee.
> >
> > But for more complex types represented by pointers, for example structs
> > such as
> > "PangoRectangle", what does type="Rectangle" direction="inout" mean in the
> > GIR
> > file? In the introspection data there seem to be two interpretations:
> >
> > (a) An argument of type "PangoRectangle*" that gets modified by the
> > function.
> > (An example is pango_matrix_transform_pixel_rectangle )
> >
> > (b) An argument of type "PangoRectangle**". The value of the
> > "PangoRectangle*"
> > pointer inside the passed in argument gets overwritten. (An example is
> > gtk_widget_destroyed.)
> >
> > In other words, in these cases it seems not clear whether (inout) refers to
> > mutability of the contents pointed to by the struct pointer, or of the
> > pointer
> > itself.
> >
> > (At least for the Haskell bindings mutability information for the contents
> > is
> > pointless, since we don't attempt to convert C type structs into pure
> > records,
> > we just keep the pointer around and access the corresponding memory
> > location
> > when one is interested in reading/writing fields, as C would.)
> >
> > Does any existing binding care about interpretation (a)? If so, it may be
> > clearer to introduce a separate annotation ("(modified)" or something like
> > that)
> > to disentangle the two possible interpretations. Otherwise we could perhaps
> > settle on interpretation (b), so there is a uniform interpretation of what
> > (inout) means for all types.
>
> Is (a) perhaps because PangoRectangle is intended to be used as a
> stack-allocated struct, so the type is PangoRectangle and the inout type is
> PangoRectangle*, whereas GtkWidget is heap-allocated so the type is
> GtkWidget* and the inout type is GtkWidget**? I don't know about
> PangoRectangle so this is just a wild guess.
>
> In any case GJS doesn't handle pango_matrix_transform_pixel_rectangle(),
> claiming it doesn't know how to transfer ownership for a non-GBoxed struct.
>
> The rules around the (inout) annotation are not entirely clear in the first
> place, as evidenced by the discussion on this bug:
> https://bugzilla.gnome.org/show_bug.cgi?id=761068#c5
>
> Regards,
> Philip C