After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 756009 - 'const gchar* const *' gets incorrectly defaulted to utf8
'const gchar* const *' gets incorrectly defaulted to utf8
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: introspection
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2015-10-03 08:26 UTC by Mikhail Zabaluev
Modified: 2018-05-24 18:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gio: Annotate GDBusObjectManagerClient signal appropriately (1.28 KB, patch)
2017-05-04 21:17 UTC, Emmanuele Bassi (:ebassi)
committed Details | Review

Description Mikhail Zabaluev 2015-10-03 08:26:08 UTC
There are some places where 'const gchar* const*' gets mapped incorrectly, despite the resolution of bug #584453.

An example is this virtual method in <gio/gdbusobjectmanagerclient.h>:

  void    (*interface_proxy_properties_changed) (GDBusObjectManagerClient   *manager,
                                                 GDBusObjectProxy           *object_proxy,
                                                 GDBusProxy                 *interface_proxy,
                                                 GVariant                   *changed_properties,
                                                 const gchar* const         *invalidated_properties);

The last parameter is introspected as:

          <parameter name="invalidated_properties" transfer-ownership="none">
            <type name="utf8" c:type="const gchar* const*"/>
          </parameter>

The default annotation here should be:
(array zero-terminated=1) (element-type utf8)
Comment 1 Mikhail Zabaluev 2015-10-04 15:27:56 UTC
Also seen with 'const gchar**', e.g. in the 'start_element' callback field of GMarkupParser.
Comment 2 infirit 2016-12-27 16:55:08 UTC
Yep, seeing this as well but then by subclassing the Gio.DBusProxy in pythoh. It causes the same invalidated properties to go wrong and in the process producing unicode errors under python3. See the thread I started on the python hackers list for some background.

[1] https://mail.gnome.org/archives/python-hackers-list/2016-December/msg00000.html
Comment 3 Emmanuele Bassi (:ebassi) 2017-05-04 21:17:18 UTC
Created attachment 351119 [details] [review]
gio: Annotate GDBusObjectManagerClient signal appropriately
Comment 4 Emmanuele Bassi (:ebassi) 2017-05-04 21:18:13 UTC
Default annotations are not a good plan: there are always too many things that can go wrong.

The correct fix is to annotate the signal appropriately.

Re-assigning to GIO, where the annotation lives.
Comment 5 Philip Withnall 2017-05-05 10:10:54 UTC
(In reply to Emmanuele Bassi (:ebassi) from comment #4)
> Default annotations are not a good plan: there are always too many things
> that can go wrong.

Not really, as long as the semantics are well defined and there are no bugs.

(That’s a big ask though.)

> The correct fix is to annotate the signal appropriately.

++
Comment 6 Philip Withnall 2017-05-05 10:11:51 UTC
Review of attachment 351119 [details] [review]:

++
Comment 7 infirit 2017-05-05 11:15:44 UTC
With patch applied to GLib and rebuilding GLib and gobject-introspection I am still seeing "<type name="utf8" c:type="const gchar* const*"/>"
Comment 8 Mikhail Zabaluev 2017-05-13 17:53:00 UTC
(In reply to Emmanuele Bassi (:ebassi) from comment #4)
> Default annotations are not a good plan: there are always too many things
> that can go wrong.

There is a difference between getting it wrong in some percentage of cases, and producing a completely bogus type mapping that's guaranteed to break.

In the example case, the proposed default mapping to array-of-utf8 will not cause invalid values to be passed to the callee, just restrict the encoding of strings that could be passed, although the method might be capable of handling arbitrary null-terminated strings. That is a lesser offense than producing a nonsensical, 100% crashy binding.
Comment 9 Philip Withnall 2017-09-11 20:39:08 UTC
Comment on attachment 351119 [details] [review]
gio: Annotate GDBusObjectManagerClient signal appropriately

I’ve pushed that patch because it’s not wrong, even if it doesn’t fix the issue. If the issue still isn’t fixed, I suspect we might need to add a gtk-doc comment for the vfunc itself, rather than just the signal. Something like the following in gdbusobjectmanagerclient.h:

/**
 * GDBusObjectManagerClientClass.interface_proxy_properties_changed:
 * @manager: blah
 * @object_proxy: blah
 * @interface_proxy: blah
 * @changed_properties: blah
 * @invalidated_properties: (array zero-terminated=1) (element-type utf8): blah
 *
 * Blah de blah.
 */

Attachment 351119 [details] pushed as 5d9ccf1 - gio: Annotate GDBusObjectManagerClient signal appropriately
Comment 10 GNOME Infrastructure Team 2018-05-24 18:15:13 UTC
-- 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/glib/issues/1087.