Re: Is this another "C locale not expected to be UTF8" testsuite problem?

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi,
> So, is that saying that, in the default "C" (==classic) locale, the widest
> char type available should be the ordinary single byte char, and hence there
> is a one-to-one mapping from char to wchar_t and no multibyte sequences involved?
>
>   On cygwin, cvt->max_length() ends up returning the value of __mb_cur_max,
> which is 6 in the default C.UTF-8 locale.
>
>   So is the generic locale support perhaps not able to handle multibyte
> encodings?  (clocale=gnu doesn't work because we have no locale_t and related
> thread-specific locale support, but we could add that if gnu locale is the
> only way to make this work.)  Or does the testsuite just have an implicit
> assumption that isn't correct here and needs adjusting for mbcs?
>   
In general, the GNU locale model is under complete control of the
maintainers, because we all more or less have available up to date
GNU/Linux systems as primary development machines. *All* the other
systems use the generic model, and we cannot say the same about those,
of course. The generic version of those facilities is available to you
under config/locale/generic/codecvt_members.cc and I believe should be
rather usable (the same can't be said in other areas, eg, named locales
are not supported at all in the generic model). My guess at the moment
would be simply that the testcases in this area should be made more
flexible vs non-GNU systems, I don't think there is anything to fix in
do_max_length per se (modulo issues with stateful encodings, unrelated,
I think).

Paolo.