g_getenv() encoding on Windows



So far g_getenv() still works like it used to, i.e. returns strings in
the system codepage (potentially a double-byte character set). I don't
recall why I didn't change it, too, to use UTF-8. (Ditto for
g_setenv() and g_unsetenv().)

Having it return UTF-8 would certainly be more in line with the rest
of the GLib API on Windows. (Also use UTF-8 for the environment
variable name, but I think it is very rare to use environment
variables with non-ASCII names? Or what do I know, maybe it is common
in some locales.)

Would it be too late to change it now, for 2.6.1?  There hasn't been
any run-time/developer distributions of GLib or GTK+ 2.6.0 for Windows
anyway, as far as I know, so it shouldn't matter much?

Of course, the same kind of DLL ABI stability measures as for the file
name related functions would be applied, i.e. GLib-using
applications/libraries built with 2.4 or earlier headers would still
get the system codepage versions.

Anybody object to this change?

--tml





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]