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
