On Fri, 2004-12-31 at 12:00 +0000, Tor Lillqvist wrote: > 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. This change sounds OK to me. If someone Windows has a copy of the environment variable with a defined encoding (environment variables on Unix, like filenames, don't have a defined encoding), then it would be good to be handling them in a way that preserves the full range of the encoding. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part