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

On Thu, Feb 11, 2010 at 4:36 PM, Paul wrote:

On 11 February 2010 06:19, OvermindDL1 wrote:

...

On Wed, Feb 10, 2010 at 7:21 AM, Paul 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.