Ian Abbott <[EMAIL PROTECTED]> writes: > Could this also be a problem on Unix systems using multibyte encoded > (UTF-8) filesystems, if not now then in the future?
I doubt it. Historically Unix has always used bytes, not characters, to name files. So it doesn't care about your encoding. I doubt whether this will ever change. Bruno Haible <[EMAIL PROTECTED]> writes: > 1) On Woe32, use 'wchar_t*' instead of 'char*' to denote pathnames. > ... > 3) Use mbtowc() to step through pathnames while looking for a backslash. I agree with you that these two methods are non-starters. > 4) Document this as a limitation. The workaround for the user is to > switch to an UTF-8 locale. or, more generally, a locale whose encoding doesn't have the problem, right? For example, EUC-JP is also safe. Or perhaps you're not mentioning this because Microsoft doesn't support EUC-JP? (I'm not familiar with their support for various encodings.) > 2) Extra code must be added for every system call to convert pathname > arguments from UTF-8 to UTF-16, and pathname results from UTF-16 > to UTF-8. Also, the user of the gnulib modules must be aware of the > semantic difference. Also, support for WindowsME and older is dropped. > > 4) For users in CJK locales on Woe32, the contents of directories with > some non-ASCII pathnames is inaccessible to GNU tools. > > Microsoft recomments approach 1. GNOME has chosen approach 2. I would > favour answer 4. Sorry, I don't quite follow. Why would gnulib itself need to care about the difference between (2) and (4)? Either way, gnulib can easily look for '/' and '\' in path names. Isn't it up to the supplier of the underlying system-call implementation, and/or the gnulib user, to decide whether (2) or (4) is in use? In other words, can't gnulib itself be agnostic about (2) versus (4)? _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
