Re: [Boost-bugs] [Boost C++ Libraries] #6690: access violation using global path object

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #6690: access violation using global path object
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-04-15 10:13:23

#6690: access violation using global path object
-------------------------------+--------------------------------------------
  Reporter:  Claudio Bley      |       Owner:  bemandawes
      Type:  Bugs              |      Status:  new       
 Milestone:  To Be Determined  |   Component:  filesystem
   Version:  Boost 1.49.0      |    Severity:  Regression
Resolution:                    |    Keywords:            
-------------------------------+--------------------------------------------

Comment (by mjklaim@…):

 After some hunting:

  - path::wchar_t_codecvt_facet() always return null
  - the current implementation of this function is supposed to
 create/initialize the object it will return;
  - the current implementation doesn't create/initialize this object if
 it's not an Apple context (not sure what the macros means here) so any
 other platform will just return the object pointer without any
 initialization, that is, undefined behaviour, meaning the pointer is null
 in debug.
  - in the case of windows, the object should have been initialized before
 the function call, as it is defined (in path.cpp) :


 {{{
 #ifdef BOOST_WINDOWS_API

   std::locale path_locale(std::locale(), new windows_file_codecvt);

   const std::codecvt<wchar_t, char, std::mbstate_t>*
     codecvt_facet(&std::use_facet<std::codecvt<wchar_t, char,
 std::mbstate_t> >
       (path_locale));

 }}}

 I suppose that an assertion checking the pointer in
 path::wchar_t_codecvt_facet() implementation would be helpful for tests.

 I don't have time to go farther, but my understanding is that either:
  - the object creation returns null (that would be surprising though)
  - the object creation never occurs.

 For this last point, I think that it would be good to check that the
 compiled code is not the "all posix" one:

 {{{


 #else  // Other POSIX

   // ISO C calls std::locale("") "the locale-specific native environment",
 and this
   // locale is the default for many POSIX-based operating systems such as
 Linux.

   // std::locale("") construction can throw (if environmental variables
 LC_MESSAGES or
   // or LANG are wrong, for example), so lazy initialization is used to
 ensure
   // that exceptions occur after main() starts and so can be caught.

   std::locale path_locale;  // initialized by
 path::wchar_t_codecvt_facet() below
   const std::codecvt<wchar_t, char, std::mbstate_t>* codecvt_facet;  //
 ditto

 # endif

 }}}


 Assuming you add an assertion in the function implementation, setting this
 variable to null would then be very helpful in tests too.

 I think I'll have to switch back to the previous boost version for now but
 I hope you can fin the problem.

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