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

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

    Hi,

  The 22_locale/codecvt/max_length/wchar_t/1.cc test (among others) is failing
for me on i686-pc-cygwin, both on HEAD and 4.3.4, configured with
clocale=generic. This started happening recently when the cygwin default C
locale was switched to use UTF-8 instead of ASCII by default. I'm trying to
understand the nature of the failure, but I'm not sure whether I'm reading the
semantic intent of the testcase correctly:

> // 22.2.1.5 - Template class codecvt [lib.locale.codecvt]
> 
> #include <locale>
> #include <testsuite_hooks.h>
> 
> // Required instantiation
> // codecvt<wchar_t, char, mbstate_t>
> void test01()
> {
>   using namespace std;
>   bool test __attribute__((unused)) = true;
>   typedef codecvt<wchar_t, char, mbstate_t> 	w_codecvt;
> 
>   locale 		loc_c = locale::classic();
>   const w_codecvt* 	cvt = &use_facet<w_codecvt>(loc_c); 
> 
>   int k = cvt->max_length();
>   VERIFY( k == 1 );
> }

  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?

    cheers,
      DaveK