[Boost-bugs] [Boost C++ Libraries] #6065: Accessing Windows paths with non-ANSI characters fails with g++

Subject: [Boost-bugs] [Boost C++ Libraries] #6065: Accessing Windows paths with non-ANSI characters fails with g++
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2011-10-27 13:20:17

#6065: Accessing Windows paths with non-ANSI characters fails with g++
---------------------------------------+------------------------------------
 Reporter:  alf.p.steinbach@…          |       Owner:  bemandawes
     Type:  Bugs                       |      Status:  new       
Milestone:  To Be Determined           |   Component:  filesystem
  Version:  Boost 1.47.0               |    Severity:  Problem   
 Keywords:  windows, paths, unicode    |  
---------------------------------------+------------------------------------
 For example, the tut5 example in Boost.Filesystem's tutorial does not work
 with g++ 4.4.1 (it fails to create the filenames with smileys), but that
 example does work with Visual C++ 10.0.

 "ANSI" here refers to the process' "ANSI codepage".

 By default in a US or Western European Windows installation that's
 codepage 1252, Windows ANSI Western.

 Cause: Boost.Filesystem uses extensions in the Dinkumware standard library
 implementation to provide general Unicode access to paths in Windows.
 g++'s standard library lacks those extension as of version 4.4.1 (and
 probably up to and including the latest version). Extending the g++
 standard library in a similar way as Dinkumware was discussed in June
 2011, <url: http://gcc.gnu.org/ml/libstdc++/2011-06/msg00066.html>, but as
 far as I know nothing more came of that.

 Boost.Filesystem v2 worked around the g++ implementation by using Windows
 short filenames and the Windows API-funcion CreateFile for creation of
 files. One problem is that the user IN PRINCIPLE can turn off generation
 of short filenames as a marginal optimization. However, Windows uses short
 filenames in the registry, reportedly MSI (the Microsoft Installer) uses
 short filenames, etc., so it's a very unlikely scenario. In the unlikely
 event that a user does turn off short names, then programs using the v2
 workaround will fail in the same way as if they didn't have the
 workaround, i.e. as currently.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/6065>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.