Incorrect implementation of codecvt<char, char, mbstate_t> in codecvt.cc

["Kristian Spangsege" <kristian dot spangsege at gmail dot com>]

The implementation of codecvt<char, char, mbstate_t> is not in
agreement with DR19 (TC). It may be due to a misinterpretation of the
text there, and if so, the problem could also be present in the
implementation of codecvt<wchar_t, char, mbstate_t> - I haven't
checked that.

>From the latest SVN version of "codecvt.cc":

> codecvt_base::result
>  codecvt<char, char, mbstate_t>::
>  do_out(state_type&, const intern_type* __from,
>         const intern_type*, const intern_type*& __from_next,
>         extern_type* __to, extern_type*,
>         extern_type*& __to_next) const
>  {
>    // _GLIBCXX_RESOLVE_LIB_DEFECTS
>    // According to the resolution of DR19, "If returns noconv [...]
>    // there are no changes to the values in [to, to_limit)."
>    __from_next = __from;
>    __to_next = __to;
>    return noconv;
>  }


'__from_next' is set equal to '__from'. According to DR19 it must
instead be set equal to '__from_end' (the next argument after
'__from'.)


>From DR19:

> If returns noconv, internT and externT are the same type and the
> converted sequence is identical to the input sequence
> [from,from_next). to_next is set equal to to, the value of state is
> unchanged, and there are no changes to the values in [to, to_limit).


The way I interpret this is as follows: If the return value is
'noconv' then it indicates that the initial section [from,from_next)
of the input can be used directly as output since the converted
sequence would by identical had it been computed.

The problem with the implementation above is that if I implement my
application to conform with DR19, then it will enter an inifinite loop
because the input position '__from_next' is not advanced.

Again with DR19 in mind, what is stated by the implementation above,
is that no conversion is required for the empty string! But this is
not enough information to be able to continue the conversion.

This issue is probably most imminent when considering iterative
conversion over long streams of data.



References:

http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/src/codecvt.cc?revision=130805&view=markup

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19


Regards,
Kristian Spangsege