FileSystem runtime error: locale::facet::_S_create_c_locale name not valid

[sleary@…]

Ok this is still broken (see Ticket #5928). On Solaris 10 (sparc) compile this...

#include <iostream> #include <boost/filesystem.hpp>

int main (void) {

std::cout << boost::filesystem::unique_path("/some/random/path/%%%%%%%").c_str() << std::endl; return 0;

}

linking against system and filesystem

I had compiled boost_1_55_0 from the site and built just filesystem and system (because program_options fails to compile with gcc 4.9.0 but thats a separate issue). I created the above example in stage/lib folder and ran..

g++ test.cpp -I../../ -L. -lboost_filesystem -lboost_system

Below are the results...

bash-3.2$ locale LANG=en_GB.UTF-8 LC_CTYPE=en_GB.ISO8859-1 LC_NUMERIC=en_GB.ISO8859-1 LC_TIME=en_GB.ISO8859-1 LC_COLLATE=en_GB.ISO8859-1 LC_MONETARY=en_GB.ISO8859-1 LC_MESSAGES=C LC_ALL= -bash-3.2$ LC_ALL=en_GB.UTF-8 LD_LIBRARY_PATH=. ./a.out terminate called after throwing an instance of 'std::runtime_error'

what(): locale::facet::_S_create_c_locale name not valid

Abort (core dumped) -bash-3.2$ LD_LIBRARY_PATH=. ./a.out terminate called after throwing an instance of 'std::runtime_error'

what(): locale::facet::_S_create_c_locale name not valid

Abort (core dumped) -bash-3.2$ LC_ALL=en_GB.ISO8859-1 LD_LIBRARY_PATH=. ./a.out terminate called after throwing an instance of 'std::runtime_error'

what(): locale::facet::_S_create_c_locale name not valid

Abort (core dumped) -bash-3.2$ LC_ALL=C LD_LIBRARY_PATH=. ./a.out /some/random/path/7fff459

This is utterly crippling and renders boost filesystem useless on Solaris 10.

[sleary@…]

the issue is that wstring is used in unique path for POSIX targets. Which to me seems wrong but i'd bet there is a good reason for it. If i revert everything back to std::string in unique path and use a char type instead then it all works fine on Solaris 10. I'm guessing this is probably not something we'd want as a standard code path so perhaps we could have some sort of build flag for OSes that have issues with wchar?

The issue seems to be something to do with the conversion from std::string to std:wstring. It only seems to work on Solaris 10 when LC_ALL=C. I'll attach a patch too.

[sleary@…]

Makes the issue go away on Solaris 10 (but not a proper fix)

[sleary@…]

Demo of the issue in action on solaris

[sleary@…]

second attachment demos why the problem exists and can also trigger the issue on linux if you set LC_ALL badly. Still fail to understand why wstring() is used at all on posix systems. Would be better to typedef a filesystem string type and avoid wstring on everything except win32.

[sleary@…]

second attachment demos why the problem exists and can also trigger the issue on linux if you set LC_ALL badly. Still fail to understand why wstring() is used at all on posix systems. Would be better to typedef a filesystem string type and avoid wstring on everything except win32.

[kevinday.home@…]

Was seeing this behavior when using parent_path. I attached 10205.parent_path.patch that I used to make my issue go away.

[Beman Dawes]

This ticket brings up several issues:

17. Should 'boost::filesystem::unique_path("/some/random/path/%%%%%%%")' work, even if the default locale is invalid (E.G. LANG=foo)?
18. Yes. As of 1.57.0 final release, an default invalid locale should only cause a failure if a conversion is explicitly called for by user code.

Action: fix unique_path code.

17. Should parent_path.patch be applied?
18. No. That constructor should no longer be calling path::codecvt(), so an invalid locale should not cause a failure.

Action: Should already be fixed in develop, but test on Linux just to be sure.

17. Should demo.cpp work, even on POSIX when the default locale is invalid?
18. No. The call to path.wstring() is an explicit request for a conversion.

Action: Check docs to see if requirement for valid locale is documented.

I'll leave this ticket open until all the action items are completed. The target is 1.57.0, but time is very short.

Thanks for the reports,

--Beman