From: Takashi Yano <takashi.yano@nifty.ne.jp>
To: cygwin@cygwin.com
Subject: Re: std::runtime_error on std::locale("")
Date: Fri, 22 Sep 2023 13:08:38 +0900 [thread overview]
Message-ID: <20230922130838.ced40a712c8a4de95be6d5a4@nifty.ne.jp> (raw)
In-Reply-To: <07777266-f285-be52-0bff-752419352e85@t-online.de>
On Thu, 21 Sep 2023 21:06:59 +0200
Christian Franke wrote:
> Brian Inglis via Cygwin wrote:
> > On 2023-09-21 10:28, Takashi Yano via Cygwin wrote:
> >> On Fri, 22 Sep 2023 01:12:04 +0900
> >> Takashi Yano wrote:
> >>> I wonder why the following code throws std::runtime_error
> >>> even though the LC_ALL is set to valid locale other than "C".
> >>> This does not occur only when LC_ALL is set to "C".
> >>>
> >>> #include <locale>
> >>> int main()
> >>> {
> >>> std::locale("");
> >>> return 0;
> >>> }
> >>>
> >>> In linux, this occurs only when the LC_ALL is set to invalid
> >>> locale (i.e. locale that is not registered in system).
> >>
> >> Similarly,
> >> std::locale("ja_JP.UTF-8")
> >> throws std::runtime_error in cygwin.
> >
> > Looks like the implementation does not like any default "" or explicit
> > "en_US.UTF-8" strings there! See example at link and below; results
> > are always the same:
> >
> > https://en.cppreference.com/w/cpp/locale/locale
> >
> > #include <iostream>
> > #include <locale>
> >
> > int main()
> > {
> > std::wcout << "User-preferred locale setting is "
> > << std::locale().name().c_str() << '\n';
> >
> > // on startup, the global locale is the "C" locale
> > std::wcout << 1000.01 << '\n';
> >
> > // replace the C++ global locale and the "C" locale with the
> > user-preferred locale
> > std::locale::global(std::locale(""));
> > // use the new global locale for future wide character output
> > std::wcout.imbue(std::locale());
> >
> > // output the same number again
> > std::wcout << 1000.01 << '\n';
> > }
> >
> > $ g++ -o c++locale{,.cc}
> > $ ./c++locale
> > User-preferred locale setting is C
> > 1000.01
> > terminate called after throwing an instance of 'std::runtime_error'
> > what(): locale::facet::_S_create_c_locale name not valid
> > Aborted (core dumped)
> >
>
> According to libstdc++ source, the internal function
> locale::facet::_S_create_c_locale() calls some __newlocale() which
> apparently does not arrive at newlocale() from cygwin1.dll. But
> cygstdc++-6.dll imports newlocale() from cygwin1.dll.
Thanks for the pointer. I looked into the cygstdc++6.dll source code,
and noticed that the code you mentioned is for glibc. In glibc,
__newlocale() is defined and newlocale() is a weak alias for that.
For generic libc (i.e. other than glibc), _S_create_c_locale() is
defined as:
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"));
}
in /libstdc++-v3/config/locale/generic/c_locale.cc.
Obviously from the code, locale other than "C" causes runtime_error.
The behaviour is as designed but not a bug in cygwin environment.
Thanks for discussion.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
next prev parent reply other threads:[~2023-09-22 4:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-21 16:12 Takashi Yano
2023-09-21 16:28 ` Takashi Yano
2023-09-21 18:08 ` Brian Inglis
2023-09-21 19:06 ` Christian Franke
2023-09-22 4:08 ` Takashi Yano [this message]
2023-09-22 7:20 ` Christian Franke
2023-09-22 5:56 ` Martin Wege
2023-09-22 12:01 ` Brian Inglis
2023-09-22 6:48 ` ASSI
2023-09-23 8:23 ` Takashi Yano
2023-09-23 8:42 ` Takashi Yano
2023-09-27 10:50 ` Takashi Yano
2023-12-31 6:57 ` Takashi Yano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230922130838.ced40a712c8a4de95be6d5a4@nifty.ne.jp \
--to=takashi.yano@nifty.ne.jp \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).