Re: [boost] [filesystem] path does not use global locale's codecvt facet - bug or feature

Subject: Re: [boost] [filesystem] path does not use global locale's codecvt facet - bug or feature
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-03-06 11:52:44

On Sun, Mar 6, 2011 at 6:32 AM, Yechezkel Mett <ymett.on.boost_at_[hidden]> wrote:
> On Thu, Mar 3, 2011 at 8:29 PM, Beman Dawes <bdawes_at_[hidden]> wrote:
...
>> "The default imbued locale provides a codecvt facet that invokes
>> Windows MultiByteToWideChar or WideCharToMultiByte API's with a
>> codepage of CP_THREAD_ACP if Windows AreFileApisANSI()is true,
>> otherwise codepage CP_OEMCP. [Rationale: this is the current behavior
>> of C and C++ programs that perform file operations using narrow
>> character string to identify paths. Changing this in the Filesystem
>> library would be too surprising, particularly where user input is
>> involved. -- end rationale]"
>
> It should use CP_ACP not CP_THREAD_ACP, because that's what the
> Windows API functions (CreateFile etc) and the C library functions
> (fopen etc) use. The C++ library functions (fstream::open etc) do in
> fact use the C global locale (by way of mbstowcs if I remember
> correctly).
>
> (CP_THREAD_ACP should never be used for converting code pages - it's
> based on the User Locale which is for sort orders and numeric
> formats.)

Hum... I marked your previous message
http://lists.boost.org/Archives/boost/2010/11/173382.php for action,
and then never did anything about it. Sorry, my mistake.

It would be very confusing and error prone if std::fstream,
boost::filesystem::fstream, and boost::filesystem operational
functions treat a narrow string filename differently. Since
std::fstream can't be changed, that implies whatever a given standard
library does should be what boost filesystem does.

That further implies that if library A does it one way, and library B
does it a different way, boost filesystem should do it the way
standard library version does it, even if that means a program using
filesystem compiled with VC++ could behave differently than if
compiled with some other compiler.

Does that make sense?

So a test case is needed that will distinguish between the C++
standard library fstream using CP_ACP, C global locale, or something
totally different.

Do you already have such test code or could you put something together?

Thanks,

--Beman