[Boost-users] [filesystem] using locales on Solaris with GCC

[JonathonS]

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
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Nathan Crookston]

Hi,

On Wed, Sep 19, 2012 at 1:44 PM, JonathonS <theju...@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

[JonathonS]

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

[Lars Viklund]

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.c...@gmail.com> wrote:
> > Hi,
> >
> > On Wed, Sep 19, 2012 at 1:44 PM, JonathonS <theju...@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 | z...@acc.umu.se

[JonathonS]

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