Created attachment 122815 [details] [review]
remove is_pointer

Needs work.  Should rename _ANY to _POINTER per owen's comments, and investigate landing this in the next version after all the other struct/array work is in and tested.

Without is_pointer, how do you specify that, say, a struct is to be passed by value?  That is, how do you distinguish these functions?

  void foo_by_value (struct blob x);
  void foo_by_ref (struct blob *x);

A different use case for is_pointer, on which I now actually depend in the Perl bindings:

To distinguish between arrays containing non-basic types and arrays containing pointers to non-basic types.  That is, the difference between

  GValue *values = g_new (GValue, n);

and

  GValue **values = g_new (GValue*, n);
  values[i] = g_new (GValue, 1);

Or, in GIR format:

  <array c:type="GValue*">
    <type name="GObject.Value" c:type="GValue"/>
  </array>

versus

  <array c:type="GValue**">
    <type name="GObject.Value" c:type="GValue*"/>
  </array>

In the array conversion code, I check for this with

  need_struct_value_semantics =
    !G_TYPE_TAG_IS_BASIC (param_tag) &&
    !g_type_info_is_pointer (param_info);

(In reply to comment #3)

> To distinguish between arrays containing non-basic types and arrays containing
> pointers to non-basic types.  

I call this "flat" versus "not flat" arrays.

I think the right solution here if we agree that is_pointer() is screwed up and broken is to have well-defined rules for whether we expect the array to be flat or not.

An initial set of rules might be:

*) If the array type is between G_TYPE_TAG_BOOLEAN and G_TYPE_TAG_GTYPE (inclusive), the array is flat
*) If the array type is anything else, it must not be flat

(In reply to comment #4)
> (In reply to comment #3)
> 
> > To distinguish between arrays containing non-basic types and arrays containing
> > pointers to non-basic types.  
> 
> I call this "flat" versus "not flat" arrays.

Note that one big intersecting issue here is if we attempt to support "flat" arrays of non-basic types, how do we know how to free them?  Do we always assume that we can free the entire array with g_free()?

(In reply to comment #4)
> I think the right solution here if we agree that is_pointer() is screwed up and
> broken is to have well-defined rules for whether we expect the array to be flat
> or not.

I don't quite understand yet what it is exactly that is wrong with is_pointer().  I always viewed it as answering the question: is there an asterisk after the type in the C declaration?  That seems perfectly well-defined and useful to me.  In which cases does it not do the right thing?

Or is it just the name that you take issue with?  But then, the implementation you suggested for is_reference() wouldn't have the semantics I described, would it?  Because something like GValue sometimes is a reference and sometimes not: the "value" argument in gtk_list_store_set_value() is a reference, the element type of the "values" argument in gtk_list_store_set_valuesv() is not.

> An initial set of rules might be:
> 
> *) If the array type is between G_TYPE_TAG_BOOLEAN and G_TYPE_TAG_GTYPE
> (inclusive), the array is flat
> *) If the array type is anything else, it must not be flat

I think the GValue* example cited above violates these rules.  Specific example: gtk_list_store_set_valuesv.  Signature:

void                gtk_list_store_set_valuesv          (GtkListStore *list_store,
                                                         GtkTreeIter *iter,
                                                         gint *columns,
                                                         GValue *values,
                                                         gint n_values);

As most GValue consumers, it expects a flat GValue array.  GI turns this into this:

          <parameter name="values" transfer-ownership="none">
            <doc xml:whitespace="preserve">an array of GValues</doc>
            <array length="3" zero-terminated="0" c:type="GValue*">
              <type name="GObject.Value" c:type="GValue"/>
            </array>
          </parameter>

And calling is_pointer() on the element type gives false, like I expect.

(In reply to comment #5)
> Note that one big intersecting issue here is if we attempt to support "flat"
> arrays of non-basic types, how do we know how to free them?  Do we always
> assume that we can free the entire array with g_free()?

Yeah, that's an issue.  Should there maybe be an annotation "free-func" for all the cases that involve returning raw allocated memory?  We could require it to take exactly one argument and return nothing.

[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/9.