Re: generic locale

[Benjamin Kosnik <bkoz at redhat dot com>]

>OK, (trivial) patch to catch attempts to create non-C locale objects
>is included for comment.  Due to caller context, we only need to catch
>"C" here.  When "POSIX", "C", "" (where LC_ALL environment is set to
>"C" or "POSIX") is provided to std::locale::locale(), it will not
>throw and it will operate exactly as before.  All other situations
>(which were not handled properly by the baseline generic
>implementation) involving calls to std::locale::locale() will throw.

I think this looks good. 

Then, you can add a hook into 

run_tests_wrapped_locale
run_tests_wrapped_env

to look for this specific exception and disable the test. This should
eliminate the noise.

>Ideally, we would mark all these failures conditionally on how
>libstdc++-v3 was configured (not readily possible with dg- framework
>AFAICS); figure out how to implement Martin's idea (not readily
>possible in the current code framework AFAICS); or (as a last resort?)
>rework them to catch the exception thrown by the generic locale implementation.

Yeah. Well. I did something like this with disabling the wchar_t tests
on platforms that don't require it.

I don't know how to do the same for named locales.

>The following tests fail for the same reason:
>
>FAIL: 27_io/filebuf_virtuals.cc execution test
>FAIL: 27_io/ios_members.cc execution test
>FAIL: 27_io/ostream_inserter_arith.cc execution test
>FAIL: 27_io/streambuf_members.cc execution test
>FAIL: 27_io/stringbuf_virtuals.cc execution test

Well, the 27_io testsuite is a mess at the moment. It would be nice to
punt on it for a bit until I get the chance to redo it entirely. If you
concentrate on 22_locale, and figure out a solution for it, I'll use the
same mechanism in 27_io. Sound like a plan?

As a first pass, please make sure that calls to locale::locale() are
replaced by locale::classic() when the "C" behavior is what is expected.
I've noticed there is some confusion in the 27_io directory about this.

This last bit might be unrelated.

>Do the other library maintainers agree that this line is an
>improvement which better reflects the state of ports using the generic
>locale implementation?  Actually, I guess I don't really care about
>the state of the testsuite failure profile (within 22_locale).  I'd
>rather install the generic/c_locale.cc patch and move on to the
>enhanced-generic which will attempt to provide better generic locale
>support.

Sounds like a very good idea. I was hoping you'd do this, and am willing
to assist. I don't think it will be too hard, as most of it has been
done and tested on linux. The real issue is getting the locale data (use
ieee-2001.1003) and making it thread-safe.

-benjamin