Boost C++ Libraries: Ticket #10205: FileSystem runtime error: locale::facet::_S_create_c_locale name not valid

sleary@… — Wed, 16 Jul 2014 19:01:21 GMT

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.

attachment set

sleary@… — Wed, 16 Jul 2014 19:02:16 GMT

attachment → 10205.patch

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

attachment set

sleary@… — Wed, 16 Jul 2014 19:26:28 GMT

attachment → demo.cpp

Demo of the issue in action on solaris

sleary@… — Wed, 16 Jul 2014 19:29:31 GMT

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@… — Wed, 16 Jul 2014 19:29:37 GMT

attachment set

kevinday.home@… — Tue, 05 Aug 2014 22:53:04 GMT

attachment → 10205.parent_path.patch

kevinday.home@… — Tue, 05 Aug 2014 22:55:01 GMT

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

status, severity, milestone changed

Beman Dawes — Wed, 29 Oct 2014 15:18:26 GMT

status new → assigned
severity Showstopper → Problem
milestone To Be Determined → Boost 1.57.0

This ticket brings up several issues:

Should 'boost::filesystem::unique_path("/some/random/path/%%%%%%%")' work, even if the default locale is invalid (E.G. LANG=foo)?
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.

Should parent_path.patch be applied?
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.

Should demo.cpp work, even on POSIX when the default locale is invalid?
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