[PATCH] PR libstdc++/80624 satisfy invariant for char_traits<char16_t>::eof()
Florian Weimer via libstdc++
libstdc++@gcc.gnu.org
Mon May 8 10:52:00 GMT 2017
On 05/08/2017 12:24 PM, Jonathan Wakely wrote:
> On 08/05/17 11:53 +0200, Florian Weimer via libstdc++ wrote:
>> On 05/05/2017 07:05 PM, Jonathan Wakely wrote:
>>> As discussed at http://stackoverflow.com/q/43769773/981959 (and kinda
>>> hinted at by http://wg21.link/lwg1200) there's a problem with
>>> char_traits<char16_t>::eof() because it returns int_type(-1) which is
>>> the same value as u'\uFFFF', a valid UTF-16 code point.
>>
>> I think the real bug is that char_traits<char16_t>::int_type is just
>> plain wrong. It has to be a signed integer,
>
> Why does it have to be signed?
Hmm. Maybe it's not strictly required. int_type(-1) as a distinct
value is likely sufficient.
>> and capable of representing values in the range 0 .. 65535.
>> char_traits<char32_t> has a similar problem. char_traits<wchar_t>
>> should be fine on glibc because WEOF is reserved, something that is
>> probably not the case for char32_t.
>
> I think there are 32-bit values which are not valid UTF-32 code
> points, including char32_t(-1) which we use for EOF.
I'm not sure if char32_t is restricted to UTF-32 codepoints (the
standard does not say, I think). But even UCS-4 is 31-bit only, so
maybe the problem does not arise there.
Thanks,
Florian
More information about the Libstdc++
mailing list