diff mbox

Various fixes for <codecvt> facets

Message ID 20170316172244.GQ4425@redhat.com
State New
Headers show

Commit Message

Jonathan Wakely March 16, 2017, 5:22 p.m. UTC 
On 16/03/17 15:23 +0000, Jonathan Wakely wrote:
>On 14/03/17 18:46 +0000, Jonathan Wakely wrote:
>>On 13/03/17 19:35 +0000, Jonathan Wakely wrote:
>>>This is a series of patches to fix various bugs in the Unicode
>>>character conversion facets.
>>>
>>>Ther first patch fixes a silly < versus <= bug that meant that 0xffff
>>>got written as a surrogate pair instead of as simply 0xff, and an
>>>endianness bug for the internal representation of UTF-16 code units
>>>stored in char32_t or wchar_t values. That's PR 79511.
>>>
>>>The second patch fixes some incorrect bitwise operations (because I
>>>confused & and |) and some incorrect limits (because I confused max
>>>and min). That fixes determining the endianness of the external
>>>representation bytes when they start with a Byte OrderMark, and
>>>correctly reports errors on invalid UCS2. It also fixes
>>>wstring_convert so that it reports the number of characters that were
>>>converted prior to an error. That's PR 79980.
>>>
>>>The third patch fixes the output of the encoding() and max_length()
>>>member functions on the codecvt facets, because I wasn't correctly
>>>accounting for a BOM or for the differences between UTF-16 and UCS2.
>>>
>>>I plan to commit these for all branches, but I'll wait until after GCC
>>>7.1 is released, and fix it for 7.2 instead. These bugs aren't
>>>important enough to rush into trunk now.
>>
>>One more patch for a problem found by the libc++ testsuite. Now we
>>pass all the libc++ tests, and we even pass a test that libc++ fails.
>>With this, I hope our <codecvt> is 100% conforming. Just in time to be
>>deprecated for C++17 :-)
>
>I've committed these to trunk, on the basis that they're intended to
>be backported to all branches anyway (fixing features that are
>currently broken in all branches). There's no point waiting if we plan
>to commit them anyway, it would just mean doing an extra backport (5,
>6, 7 *and* 8).
>
>Backports will be done soon.

This fixes a dumb error, where I didn't stop using a "mode_t" typedef
that I introduced at one point and then removed again. It happened to
match a POSIX type on GNU/Linux and worked OK, but not on other
targets.

Fixed like so, committed as obvious.
diff mbox

Patch

commit ce38a7334ea88e8d5fa5685916067cba9e4a7403
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Mar 16 17:16:44 2017 +0000

    PR libstdc++/79980 fix target type of cast
    
    	PR libstdc++/79980
    	* src/c++11/codecvt.cc (to_integer(codecvt_mode)): Fix target type.

diff --git a/libstdc++-v3/src/c++11/codecvt.cc b/libstdc++-v3/src/c++11/codecvt.cc
index ef38267..02866ef 100644
--- a/libstdc++-v3/src/c++11/codecvt.cc
+++ b/libstdc++-v3/src/c++11/codecvt.cc
@@ -34,7 +34,7 @@  _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // The standard doesn't define these operators, which is annoying.
   static underlying_type<codecvt_mode>::type
   to_integer(codecvt_mode m)
-  { return static_cast<mode_t>(m); }
+  { return static_cast<underlying_type<codecvt_mode>::type>(m); }
 
   static codecvt_mode& operator&=(codecvt_mode& m, codecvt_mode n)
   { return m = codecvt_mode(to_integer(m) & to_integer(n)); }