public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "tsyvarev at ispras dot ru" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/40184] New: locale(const char* std_name) can create invalid facets for nonuniform locale Date: Mon, 18 May 2009 11:31:00 -0000 [thread overview] Message-ID: <bug-40184-16694@http.gcc.gnu.org/bugzilla/> (raw) Constructor locale(const char* std_name), when called with name of nonuniform locale (like "LC_CTYPE=...;LC_COLLATE=...;..."), can create locale with incorrect content of some its facets: these facets differ from facets of locale, created via locale(const locale& other, const char* std_name, category) with subsequent replacing of categories. While this locale has same name as argument of locale(const char* std_name). This behaviour contradicts description of member-function name() (22.1.1.3, p5): If *this has a name, then locale(name().c_str()) is equivalent to *this. Example below demonstrates contradiction of this statement on curr_symbol() property of moneypunct<wchar_t> facet: #include <locale> #include <cassert> int main() { using namespace std; locale loc(locale("C"), "en_GB.utf8", locale::monetary); const moneypunct<wchar_t>& mp = use_facet<moneypunct<wchar_t> >(loc); locale loc_copy(loc.name().c_str()); const moneypunct<wchar_t>& mp_copy = use_facet<moneypunct<wchar_t> >(loc_copy); assert(mp.curr_symbol() == mp_copy.curr_symbol()); return 0; } It seems, the source of the problem is a method of filling properties of named locale. E.g., for moneypunct<wchar_t> facet, the method performs the following: 1)sets the current POSIX locale with given name, 2)sets some properties of C++ locale, using __nl_langinfo_l() function call, 3)the rest properties of C++ locale are obtained from char-versions of them using mbsrtowcs()-like functions. But mbsrtowcs() use current LC_CTYPE category, which name may differ from the name of LC_MONETARY category in nonuniform locale. So mbsrtowcs() assumes that string, passed to it, belongs to one charset(according to LC_TYPE category name), while it belongs to the another (according to LC_MONETARY category name). This fact entails wrong property value, obtained via such call to mbsrtowcs(). Up to garbage, because implementation doesn't verify result of mbsrtowcs(), which doesn't set terminating '\0' in case of error. The fact, that the implementation doest't verify result of mbsrtowcs(), also seems strange - absence of terminating '\0' may lead to SIGFAULT. -- Summary: locale(const char* std_name) can create invalid facets for nonuniform locale Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tsyvarev at ispras dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40184
next reply other threads:[~2009-05-18 11:31 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-05-18 11:31 tsyvarev at ispras dot ru [this message] 2009-05-18 12:40 ` [Bug libstdc++/40184] " paolo dot carlini at oracle dot com 2009-05-18 14:37 ` tsyvarev at ispras dot ru 2009-05-18 15:04 ` paolo dot carlini at oracle dot com 2009-05-19 18:21 ` paolo at gcc dot gnu dot org 2009-05-19 18:24 ` paolo dot carlini at oracle dot com
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=bug-40184-16694@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /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: linkBe 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).