Re: [Boost-users] [filesystem] wpath and fopen() on windows

Subject: Re: [Boost-users] [filesystem] wpath and fopen() on windows
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-02-11 18:50:30

On Thu, Feb 11, 2010 at 4:36 PM, Paul <elegant_dice_at_[hidden]> wrote:
>
>
> On 11 February 2010 06:19, OvermindDL1 <overminddl1_at_[hidden]> wrote:
>>
>> On Wed, Feb 10, 2010 at 7:21 AM, Paul <elegant_dice_at_[hidden]> wrote:
>> > Hi,
>> > What is the best way for me to use boost::filesystem::wpath with a 3rd
>> > party
>> > C library that expects a const char* filename, on Windows?
>> > On linux, its simple: my_file.to_external_string() Â but on windows that
>> > gives me a wide-character string.
>> > So far the only thing I can think of is to roll my own wstring --> UTF8
>> > conversion function, but I'm not even sure that is correct (will fopen()
>> > work with UTF-8 encoded filenames on windows?).
>> > thanks,
>>
>> That is correct. Â On Windows XP and higher *all* file function use
>> wide-character strings. Â Their are ascii versions of the same
>> functions, but you can see the implementation and they just convert
>> the string to a wide then call the normal function, hence having it
>> wide in the first place saves you time. Â It seems pretty stupid to
>> convert from wide to ascii just to have the system waste even more
>> time converting from ascii back to wide. Â I do not think file
>> functions will work with all UTF-8 though as UTF-8 support in the
>> Windows kernel is... lacking...
>
>
> This sounds like interacting with many C programs that open files could be a
> big problem...
>
> Take for example, zlib
> http://zlib.net/manual.html#Gzip
>
> fs::wpath my_path = whatever;
>
> gzFile f = gzopen( my_path.NARROW(), "r" );
>
> ??
>
> In zlib's case, I might be saved because I can call gzopen on a
> file-descriptor, but there are other libraries (one of which I am using)
> that will only accept a char* filename...
>
> What do I do?

You should submit a patch to fix those libraries to accept a file
handle instead of a file name, file handles are universal and work
properly everywhere, but yes, the C function calls can break horribly
on, say, a Japanese regional Windows computer (of which one of my
friends is and has set up, I love testing my programs on it to make
sure they still work).  Any library that accepts only 8-bit character
filenames is broken, they did not take into account regionalization at
all and need patches to be fixed (hence they should have something
that accepts a file handle since those *always* work, or at the very
least accept wide and narrow filenames).

But yes, do know that Windows 2000 and higher uses wchar natively for
*ALL* filesystem functions so it can support regionalization.