GNOME Bugzilla – Bug 767266
Add missing filename type annotations
Last modified: 2018-05-02 17:12:45 UTC
Created attachment 329154 [details] [review] Add missing filename type annotations I'm currently working on improving filename handling in PyGObject which depends on filenames being annotated as such. See bug 746564
Review of attachment 329154 [details] [review]: It seems a little dubious to me to apply this to all comamndline arguments
A filename in glib is bytes on Unix and utf-8 on Windows. I'm not sure what the encoding of commandline args is, I guess depending on the context either data, ascii or filenames? Imo marking them as filenames is better than what we have now because: * Both filenames and argv in glib are null terminated bytes on Unix and utf-8 on Windows * In Python both things get treated the same, so at least in PyGObject this is all the information we need. Not sure about other bindings.
Created attachment 329315 [details] [review] Add missing filename type annotations Now without the argv changes
Comment on attachment 329154 [details] [review] Add missing filename type annotations I've posted to gir-devel-list some weeks ago and got one endorsement and no objections. https://mail.gnome.org/archives/gir-devel-list/2016-June/msg00000.html So, I'd like to propose the first patch for inclusion again.
(In reply to Christoph Reiter (lazka) from comment #2) > A filename in glib is bytes on Unix and utf-8 on Windows. I'm not sure what > the encoding of commandline args is, I guess depending on the context either > data, ascii or filenames? > How GOption treats encoding is documented in the GLib documentation: * If an option is declared to be of type string or filename, GOption takes * care of converting it to the right encoding; strings are returned in * UTF-8, filenames are returned in the GLib filename encoding. Note that * this only works if setlocale() has been called before * g_option_context_parse().
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
-- 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/gtk/issues/633.