[filesystem] using locales on Solaris with GCC
Hi, I am currently battling a buggy locale implementation (or lack thereof) in GCC on Solaris, which is affecting my use of boost::filesystem. Please have a look at the following thread for more information regarding this: http://gcc.gnu.org/ml/gcc-help/2009-09/msg00212.html In short, Solaris/GCC has a huge limitation that it does not support locales besides "C" or "POSIX". I talked to the GCC folks regarding this issue, and they said that at ONE time, GCC implemented the locale support for Solaris, but over time, the code was not maintained and therefore died :( This is very unfortunate because after looking through the boost filesystem code (boost/libs/filesystem/src/path.cpp), I found out that it creates a default locale by invoking std::locale("") (boost/libs/filesystem/src/path.cpp @ line 911) . Therefore, if my client sets the locale to anything but "C" or "POSIX", when it tries to create the default locale object via std::locale(""), it throws a runtime exception which crashes my program. So, my question is whether anyone knows of a work-around for this? I came up with one idea, but it seems very hackish. I can try to construct a boost::filesystem::path object and try to catch the exception thrown by std::locale(""). If the exception is thrown, I can set the environment variable to "C" or "POSIX" and continue with the program. My other idea is to manually patch boost::filesystem::path to use the following code to create the default locale. (again line 911 in path.hpp) try { use std::locale("") as the default locale; } catch ( std::runtime_error& ) { // We were unable to construct a locale, now use the global locale. use std::locale() as the default locale; } using std::locale() as the default will *always* succeed since it will just use whatever the current global locale is. My concern with this, is that I'll have to manually patch boost for this. Thanks, J
Hi, On Wed, Sep 19, 2012 at 1:44 PM, JonathonS <thejunkjon@gmail.com> wrote:
Hi,
I am currently battling a buggy locale implementation (or lack thereof) in GCC on Solaris, which is affecting my use of boost::filesystem.
Please have a look at the following thread for more information regarding this: http://gcc.gnu.org/ml/gcc-help/2009-09/msg00212.html
In short, Solaris/GCC has a huge limitation that it does not support locales besides "C" or "POSIX". I talked to the GCC folks regarding this issue, and they said that at ONE time, GCC implemented the locale support for Solaris, but over time, the code was not maintained and therefore died :(
So, my question is whether anyone knows of a work-around for this?
I haven't tried it, but would using boost::locale in conjunction with filesystem work? Perhaps imbuing an ICU-backed locale would help, as shown in: <http://www.boost.org/doc/libs/1_50_0/libs/locale/doc/html/default_encoding_under_windows.html> HTH, Nate
Thanks Nate for the link. It does look promising, but I am using Boost 1.47.0 and I can't upgrade unfortunately. It looks like Locale was introduced in Boost 1.49.0. Is there a way to tell boost filesystem to not use locales and to treat all paths as UTF-8? Solaris paths are native UTF-8 and my customers will always pass in UTF-8 paths so there is no reason for them to be translated. Thanks, J On Wed, Sep 19, 2012 at 1:58 PM, Nathan Crookston <nathan.crookston@gmail.com> wrote:
Hi,
On Wed, Sep 19, 2012 at 1:44 PM, JonathonS <thejunkjon@gmail.com> wrote:
Hi,
I am currently battling a buggy locale implementation (or lack thereof) in GCC on Solaris, which is affecting my use of boost::filesystem.
Please have a look at the following thread for more information regarding this: http://gcc.gnu.org/ml/gcc-help/2009-09/msg00212.html
In short, Solaris/GCC has a huge limitation that it does not support locales besides "C" or "POSIX". I talked to the GCC folks regarding this issue, and they said that at ONE time, GCC implemented the locale support for Solaris, but over time, the code was not maintained and therefore died :(
So, my question is whether anyone knows of a work-around for this?
I haven't tried it, but would using boost::locale in conjunction with filesystem work? Perhaps imbuing an ICU-backed locale would help, as shown in: <http://www.boost.org/doc/libs/1_50_0/libs/locale/doc/html/default_encoding_under_windows.html>
HTH, Nate _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Wed, Sep 19, 2012 at 08:42:12PM -0700, JonathonS wrote:
Thanks Nate for the link. It does look promising, but I am using Boost 1.47.0 and I can't upgrade unfortunately. It looks like Locale was introduced in Boost 1.49.0.
Is there a way to tell boost filesystem to not use locales and to treat all paths as UTF-8? Solaris paths are native UTF-8 and my customers will always pass in UTF-8 paths so there is no reason for them to be translated.
You could probably stub up a no-op codecvt and pass that in wherever Boost.Filesystem has an default codecvt parameter. It is only actually _used_ when you use the non-native string type, if you only ever use narrow strings, the actual codecvt functionality will never be called. As I understand it, your explosions is due to the codecvt() instantiation itself, not the actual use of it. As a closing note, don't top-post, try to trim out unnecessary context and reply in-line.
On Wed, Sep 19, 2012 at 1:58 PM, Nathan Crookston <nathan.crookston@gmail.com> wrote:
Hi,
On Wed, Sep 19, 2012 at 1:44 PM, JonathonS <thejunkjon@gmail.com> wrote:
Hi,
I am currently battling a buggy locale implementation (or lack thereof) in GCC on Solaris, which is affecting my use of boost::filesystem.
Please have a look at the following thread for more information regarding this: http://gcc.gnu.org/ml/gcc-help/2009-09/msg00212.html
In short, Solaris/GCC has a huge limitation that it does not support locales besides "C" or "POSIX". I talked to the GCC folks regarding this issue, and they said that at ONE time, GCC implemented the locale support for Solaris, but over time, the code was not maintained and therefore died :(
So, my question is whether anyone knows of a work-around for this?
I haven't tried it, but would using boost::locale in conjunction with filesystem work? Perhaps imbuing an ICU-backed locale would help, as shown in: <http://www.boost.org/doc/libs/1_50_0/libs/locale/doc/html/default_encoding_under_windows.html>
-- Lars Viklund | zao@acc.umu.se
Thanks Lars for the help.
You could probably stub up a no-op codecvt and pass that in wherever Boost.Filesystem has an default codecvt parameter.
I thought of this idea, but unfortunately, this would require the devs to remember to pass in the stubbed codecvt implementation whenever they create a filesystem::path object. I guess I could create a helper function to return a path object, but then again, that would require them to use my helper function. I don't think they would like this. Is there a way to say, "always use this codecvt for all locales" ?
As I understand it, your explosions is due to the codecvt() instantiation itself, not the actual use of it.
Correct. Whenever boost filesystem gets instantiated, it tries to get the default locale via the invocation std::locale("") which seems to call the constructor for codecvt. If I was able to replace std::locale("") with std::locale(), then I think my problem would be solved because then this would force my customer's to set their locale via std::locale::global(...) and let them handle the issue :) Thanks, J
participants (3)
-
JonathonS -
Lars Viklund -
Nathan Crookston