Re: g_filename_to_utf8 limitations on Win32

On 2004.10.29 04:26 Tor Lillqvist wrote:

Hmm, true. We seem to need a g_argv_to_utf8() function?

gchar **
g_argv_to_utf8 (int argc,
char **argv);

I suspect this will cause memory leaks unless you do some very fancy footwork. Owen's idea of using GOption looks to have the equivalent functionality without some of the caveats (eg., users calling g_argv_to_utf8 before option processing), but I don't know GOption well enough yet to be sure. Looks like I've got some reading up to do next week :-)

(Of course, one cannot be 100% sure that command line parameters are
in the supposed filename encoding on Unix. It's quite possible that
one has LANG set to for instance en_US.UTF-8 but still uses an xterm
and/or shell that actually generate ISO-8859-1 or whatever. Yes, this
is a mess, and I usually tell my users to avoid non-ASCII chars in
file names on Unix. We have a mix of Solaris 7, 8 and 9, and RHEL3
(plus gazillons of Windowses of course). With just Solaris 9 and Linux
UTF-8-everywhere would be possible, but on Solaris 7 and 8, it just
isn't feasible. Throw in multi-protocol (NFS+CIFS) file servers that
have their own quirks and want to know what encoding filenames coming
in through NFS are in (per-NFS-client!, although locale settings are
per-process...) and things can get hairy...)

Yes, I agree it's a mess. This is less of an issue to me since all my current users are on win32 and if we do ship a Unix system I can choose the version of Linux to ship that's best suited to the task. From glib's point of view, I think we just need to continue to ensure that G_BROKEN_FILENAMES will switch the encoding of filenames as command line arguments under Unix.


J. Ali Harlow
ali juiblex co uk

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