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 738185 - Misleading language about "file name encoding" in the docs on g_environ_* and GSubprocessLauncher
Misleading language about "file name encoding" in the docs on g_environ_* and...
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
2.42.x
Other All
: Normal minor
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2014-10-08 21:22 UTC by Mikhail Zabaluev
Modified: 2015-06-05 18:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
glib/genviron.c, GSubprocessLauncher: ain't no "filename encoding" (4.87 KB, patch)
2014-10-08 21:23 UTC, Mikhail Zabaluev
reviewed Details | Review
glib/genviron.c, GSubprocessLauncher: ain't no "filename encoding" (5.12 KB, patch)
2014-10-09 16:33 UTC, Mikhail Zabaluev
committed Details | Review

Description Mikhail Zabaluev 2014-10-08 21:22:08 UTC
The API doc comments have vague language about the environment variable strings being in the "GLib file name encoding", at the same time admitting they could be arbitrary byte strings. This is actually a misnomer: nothing should prevent a UNIX process from interpreting env vars in any encoding they please, and no encoding should necessarily be applied to e.g. UTF-8 data sources in order to make them useful in a process environment. The encoding of variable values may be decided on case-by-case basis: the filename encoding for path-like variables, the locale encoding for human-readable text, or possibly even strictly UTF-8 in some other cases.
Comment 1 Mikhail Zabaluev 2014-10-08 21:23:29 UTC
Created attachment 288079 [details] [review]
glib/genviron.c, GSubprocessLauncher: ain't no "filename encoding"

Removed all mentions of GLib file name encoding referring to
the environment strings. The env var content has no defined relation
to GLib's notion of filename encoding, or any encoding whatsoever.
It would be wrong to pass all UTF-8 strings through
g_filename_from_utf8() in order to put them into the environment,
for one thing.
Comment 2 Allison Karlitskaya (desrt) 2014-10-09 13:43:06 UTC
Review of attachment 288079 [details] [review]:

Other than a small nitpick, this generally looks good.

::: gio/gsubprocesslauncher.c
@@ +283,3 @@
  * processes launched from this launcher.
  *
+ * On UNIX, the variable name can be an arbitrary byte string.

This statement is slightly too strong: it cannot contain '='.

The other statement was restrictive in nature whereas this one seems more permissive, which is why I think the exception needs to be mentioned here, or the statement reworked to something weaker like "variable name has no particular encoding".
Comment 3 Mikhail Zabaluev 2014-10-09 16:33:26 UTC
Created attachment 288145 [details] [review]
glib/genviron.c, GSubprocessLauncher: ain't no "filename encoding"

Added the requirement on not containing '=' in the description of
*_setenv*() functions.
Comment 4 Allison Karlitskaya (desrt) 2014-10-09 18:10:35 UTC
Review of attachment 288145 [details] [review]:

Sure.  Thanks.
Comment 5 Matthias Clasen 2015-06-05 18:57:36 UTC
Attachment 288145 [details] pushed as 16190d2 - glib/genviron.c, GSubprocessLauncher: ain't no "filename encoding"