GNOME Bugzilla – Bug 738186
No way to properly annotate bytestring arrays (want type bytestring)
Last modified: 2018-02-08 12:30:42 UTC
Currently the environment variable arrays as used by g_environ_*(), g_spawn_*(), and elsewhere are automatically assigned (element-type utf8) in introspection. This is wrong and it will cause representation problems in bindings. However, there does not seem to be a way to fix this by explicit annotation without a bytestring type, which is not present in GI. The bytestring type would also come as a shorthand to (array zero-terminated=1) (element-type guint8): , as similarly used on some string pointer parameters to cancel the utf8 auto-annotation (that is furthermore broken due to bug #737883). Another way to solve the issue would be to remove any process-spawning APIs from introspection altogether, as seems to be the case for GSubprocessLauncher. But the GDesktopAppInfo launch methods with GAppLaunchContext would seem like valuable Gio functionality to lose or cripple in bindings just because of the data representation problems.
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
This is also where annotation for g_variant_new_bytestring_array() falls flat.
For backward compatibility, (type bytestring) may desugar to (array zero-terminated=1) (element-type guint8). This way, no changes to GIR or typelib formats are necessary, only the scanner needs to understand the new pseudo-type annotation.
(In reply to Mikhail Zabaluev from comment #3) > For backward compatibility, (type bytestring) may desugar to > (array zero-terminated=1) (element-type guint8). This way, no changes to GIR > or typelib formats are necessary, only the scanner needs to understand the > new pseudo-type annotation. Well, that, and the consumers of GIR and typelibs will also need to deal with dynamically allocated C arrays as elements of an array.
Would (type filename) achieve the required effect?
(In reply to Phil Clayton from comment #5) > Would (type filename) achieve the required effect? No, filename implies the GLib filename encoding (ugh) and may be actually bound to the programming environment's favorite type representation of pathnames, to deal with the restricted syntax required there. In Rust, for example, it could be bound to Path: http://doc.rust-lang.org/std/path/index.html
-- 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/118.