Re: [PATCH] Various fixes for <codecvt> facets

[Jonathan Wakely <jwakely at redhat dot com>]

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.

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)); }