Re: [PATCH] PR libstdc++/80624 satisfy invariant for char_traits<char16_t>::eof()

[Jonathan Wakely <jwakely at redhat dot com>]

On 08/05/17 13:37 +0200, Stephan Bergmann via libstdc++ wrote:
> On 05/08/2017 12:19 PM, Jonathan Wakely via libstdc++ wrote:
> > Changing the semantics of to_int_type for U+FFFF is far less likely to
> > affect any ABIs (it's a constexpr function so it's possible somebody
> > is using the value of to_int_type(char_type(-1)) as a template
> > argument, but it seems unlikely. It's a much smaller change, "allowed"
> > by http://www.unicode.org/faq/private_use.html#nonchar10 and it only
> > affects a noncharacter that is not intended for interchange anyway.
>
> I'm not convinced that a C++ implementation should be allowed to 
> rewrite U+FFFF -> U+FFFD in this manner.  Noncharacters not being 
> suitable for interchange IMO doesn't imply that an application 
> shouldn't be able to write them out and read them back in.  (And 
> <http://www.unicode.org/versions/corrigendum9.html> "Corrigendum #9: 
> Clarification About Noncharacters" seems to support that view.)
>
> To me, it feels like this change is not an improvement over keeping 
> living with the current defect.

So rather than transforming U+FFFF into U+FFFD you'd prefer to write
nothing instead?

#include <sstream>
#include <cassert>

int main()
{
 std::basic_ostringstream<char16_t> s;
 s.put(u'\uFFFF');
 assert( s.str().length() == 1 );
}

a.out: ex.cc:8: int main(): Assertion `s.str().length() == 1' failed.
Aborted (core dumped)

With my patch it inserts U+FFFD.