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
>> 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
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 doub
Ian Abbott wrote:
> Wouldn't it be possible to link against unicows.dll to support
> Win95/98/ME?
No. unicows.dll is a closed-source library which is not normally part
of a Woe32 installation. You cannot distribute unicows.dll with the
binaries of a GPLed program - this would be a violation of the
On 27/04/2005 15:56, Bruno Haible wrote:
Tor Lillqvist <[EMAIL PROTECTED]> brought this up:
The technique of searching for directory separators in strings through the
ISSLASH macro does, on Woe32, not support non-ASCII pathnames in most CJK
locale encodings. Why? ISSLASH looks for a _byte_ with val