https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79511
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2017-02-14
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to ww898 from comment #0)
> Hi,
>
> I found two issues in std::codecvt_utf8_utf16 for GCC v5.4 (Clang v3.8 has
> no issues here):
>
> 1. \xEF\xBF\xBF (UTF8) convered to \xD7FF\xDFFF (UTF16), but should be
> \xFFFF (UTF16). (Attention: \xD7FF is not is high surrogate region
> [D800..DBFF]). Please see non character representation table in
> http://www.unicode.org/faq/private_use.html#noncharacters
Please provide a testcase, this is not a helpful bug report.
You were asked to read https://gcc.gnu.org/bugs/ first.
> 2. std::codecvt_utf8_utf16 requires std::little_endian on x86_64. Otherwise
> big endian order is used as default!
I think that's correct, the default is specified by the C++ standard and
doesn't depend on the target platform:
"If (Mode & little_endian), the facet shall generate a multibyte sequence in
little-endian order, as opposed to the default big-endian order."
