[Bug libstdc++/66464] codecvt_utf16 max_length returning incorrect value

["redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66464

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-06-09
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Leo Carreon from comment #0)
> I just noticed that codecvt_utf16<char32_t>::max_length() is returning 3.
> 
> This appears to be the wrong value because a surrogate pair is composed of 4
> bytes therefore max_length() should at least be returning 4.

Agreed, I think that's just a mistake.

I wrote this comment in the code:

int
codecvt<char16_t, char, mbstate_t>::do_max_length() const throw()
{
  // Any valid UTF-8 sequence of 3 bytes fits in a single 16-bit code unit,
  // whereas 4 byte sequences require two 16-bit code units.
  return 3;
}

But that reasoning (even if it's correct!) doesn't apply to
codecvt_utf16<char32_t>.

> I'm also wondering whether the BOM should be taken into account.  If it so
> happens that at the beginning of a UTF-16 string which has a BOM and it so
> happens to start with a surrogate pair, 6 bytes have to be consumed to
> generate a single UCS-4 character.
> 
> Should the same thing be considered with
> codecvt_utf8<char32_t>::max_length() which currently returns 4.  Taking into
> account the BOM and the longest UTF-8 character below 0x10FFFF, shouldn't
> max_length() return 7.
> 
> I'm not really sure if the BOM should be taken into account because the
> standard's definition for do_max_length() simply says the maximum number of
> input characters that needs to be consumed to generate a single output
> character.

That's a very good question.