Bruno Haible <[EMAIL PROTECTED]> writes:
> In approach (2) LIBDIR will be an UTF-8 encoded pathname. The ISSLASH
> operation will therefore work correctly. However, fopen() expects a
> string in locale encoding, not in UTF-8 encoding. Therefore we have
> to replace the last line with
OK, I'm star
On 28/04/2005 15:56, Bruno Haible wrote:
fp = fopen (file_name, "r");
In approach (2) LIBDIR will be an UTF-8 encoded pathname. The ISSLASH
operation will therefore work correctly. However, fopen() expects a
string in locale encoding, not in UTF-8 encoding. Therefore we have
to replace the la
Paul Eggert wrote:
> 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
>> the byte 0x5C occurs as second byte of some multibyte characters. If such a
>> character is used inside a directory name, code that uses ISSLASH does not
>> work correctly. All gnulib modules that use ISSLASH are affected.
>Could this also be a problem on Unix systems using multibyte encoded
>(
Hello,
Ian Abbott asked:
> > Could this also be a problem on Unix systems using multibyte encoded
> > (UTF-8) filesystems, if not now then in the future?
no, this cannot happen, because of how UTF-8 is designed:
1) If a character is represented by a single byte, then the the most
significant bit
On 28/04/2005 02:18, Tor Lillqvist wrote:
the byte 0x5C occurs as second byte of some multibyte characters. If such a
character is used inside a directory name, code that uses ISSLASH does not
work correctly. All gnulib modules that use ISSLASH are affected.
Could this also be a problem on Unix sy
