Re: [bug-gnulib] Re: ISSLASH on Woe32

[Paul Eggert]

Ian Abbott <address@hidden> 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 <address@hidden> 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)?