apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Is --enable-utf8 working everywhere?
Date Wed, 17 Jul 2002 04:44:54 GMT
At 11:31 PM 7/16/2002, Brane wrote:
>William A. Rowe, Jr. wrote:
>
>>At 10:57 PM 7/16/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>>BTW; I just noticed that the apr_filepath_* functions on Windows can 
>>potentially fail horribly if the paths are not UTF-8 (so, not 
>>IF_WIN_OS_IS_UNICODE) and the locale uses Shift-JIS, because '\' can be 
>>the second byte in a SJIS doublebyte char. Talk about fun.
>>
>>
>>That's exactly correct.  apr on win32 is a utf8 only filesystem.
>>
>>It was the only natural way to map the entire unicode filesystem
>>into apr, in a platform-neutral way.
>
>
>O.K., that's fine. But then, when do the ELSE_WIN_OS_IS_ANSI conditions 
>kick in? On what platforms? (Just curious, that's all.)

NEVER.

Sorry for the confusion, that should probably be better hidden.  The ANSI 
stuff
is magic to make the entire blocks of code evaporate when we toggle a
/D WINNT build.

One major problem with the APR_HAS_UNICODE_FS garbage ... it isn't
strictly true.  On Win9x [when compiled for WIN32 - both NT and 9x] that
macro will be set, but it lies.

I have -absolutely-no- objection to having a function that returns the local
codepage (utf-8 on NT, the lcs on 9x, and the appropriate tag from the
c locale on other platforms)  if we want to identify the codepage of the
filesystem.

I've just never gotten that far.

Bill



Mime
View raw message