This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/66492] New: std::messages<wchar_t> unsafe and inefficient
- From: "msebor at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 10 Jun 2015 16:04:31 +0000
- Subject: [Bug libstdc++/66492] New: std::messages<wchar_t> unsafe and inefficient
- Auto-submitted: auto-generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66492
Bug ID: 66492
Summary: std::messages<wchar_t> unsafe and inefficient
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The following observations were made in a private conversation with
jwakely@redhat.com, after reading the libstdc++ implementation of the
messages<wchar_t> facet. Jonathan asked me to open a bug for the record. I
have no test case and not all the points may be accurate or even correct.
The messages<wchar_t> facet in libstdc++ looks like it could be improved.
AFAICS, it does three codeset conversions:
1) one in libc (induced by bind_textdomain_codeset),
2) another in do_get to convert the default string to the external encoding
(this seems entirely unnecessary), and
3) finally one of the libc text to the internal encoding (this one is
unavoidable).
It's not clear to me that (1) will do the right thing when the locale argument
to messages<wchar_t>::open has a user-defined codecvt facet.
(3) doesn't seem to handle codeset conversion errors correctly (even though the
standard doesn't require it, it should probably return the default string
instead of an empty or truncated string). Using alloca for what's essentially
user-controlled strings also seems risky.