[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <C7GP1N41MKA5.3MFDNXIRUIS4M@mussels>
Date: Mon, 30 Nov 2020 12:12:50 -0300
From: Érico Nogueira <ericonr@...root.org>
To: "Samuel Holland" <samuel@...lland.org>, <musl@...ts.openwall.com>, "Dong
Brett" <brett.browning.dong@...il.com>
Subject: Re: Question on C++ locale
On Mon Nov 30, 2020 at 11:39 AM -03, Samuel Holland wrote:
> On 11/30/20 7:44 AM, Érico Nogueira wrote:
> > On Mon Nov 30, 2020 at 8:35 AM -03, Szabolcs Nagy wrote:
> >> * Dong Brett <brett.browning.dong@...il.com> [2020-11-30 18:41:33
> >> +0800]:
> >>> However, the following C++ code does not work (our software uses std::locale in C++ standard library for locale related stuff):
> >>> #include <langinfo.h>
> >>> #include <locale.h>
> >>> #include <locale>
> >>> using namespace std;
> >>> int main()
> >>> {
> >>> std::locale::global(locale(""));
> >>> initscr();
> >>> printw("LC_ALL: %s\n", setlocale(LC_ALL, NULL));
> >>> printw("C++ locale: %s\n", locale().name().c_str());
> >>> printw("CODESET: %s\n", nl_langinfo(CODESET));
> >>> printw("Hello, world!\n");
> >>> printw("你好，世界!\n");
> >>> refresh();
> >>> getch();
> >>> endwin();
> >>> return 0;
> >>> }
> >>
> >> fwiw for me even the first line fails.
> >> i don't know how c++ locales are supposed to work.
> >
> > From [1], it seems that C++ locales are supposed to affect the global
> > locale as well, so they should call setlocale() when appropriate.
> >
> > - [1] https://www.cplusplus.com/reference/locale/locale/
> >
> > Unfortunately, I assume libstdc++ uses their generic locale support on
> > musl... From gcc-10.2.0/libstdc++-v3/config/locale/generic/c_locale.cc:
> >
> > void
> > locale::facet::_S_create_c_locale(__c_locale& __cloc, const char* __s,
> > __c_locale)
> > {
> > // Currently, the generic model only supports the "C" locale.
> > // See http://gcc.gnu.org/ml/libstdc++/2003-02/msg00345.html
> > __cloc = 0;
> > if (strcmp(__s, "C"))
> > __throw_runtime_error(__N("locale::facet::_S_create_c_locale "
> > "name not valid"));
> > }
> >
>
> I don't know for sure that it's the right thing to do, but I have been
> patching
> out that error for the last several years[1] and so far I have not
> noticed any
> negative effects. Adelie, which is very thorough about testing, has also
> carried
> the patch for a while[2].
>
> Samuel
>
> [1]:
> https://github.com/smaeul/portage/blob/c744774a/patches/sys-devel/gcc/gcc-5.4.0-locale.patch
> [2]: https://code.foxkit.us/adelie/packages/-/commit/d09b437d
Are those patches correct in functionality? The GNU version is:
void
locale::facet::_S_create_c_locale(__c_locale& __cloc, const char* __s,
__c_locale __old)
{
__cloc = __newlocale(1 << LC_ALL, __s, __old);
if (!__cloc)
{
// This named locale is not supported by the underlying OS.
__throw_runtime_error(__N("locale::facet::_S_create_c_locale "
"name not valid"));
}
}
It tries to create a locale object, which the generic code doesn't do.
In the generic case, _S_create_c_locale is basically a noop, and I'd
assume localization wouldn't work, even if it does avoid the runtime
abort.
I will try it out locally when I get the time.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
