libstdc++, generic locale configuration, and c++0x

[Doug Semler <dougsemler at gmail dot com>]

While investigating a multithread segfault on mingw32 systems, I
discovered that the cause of the problem is a data race introduced in
the config/locale/generic/c_locale.cc and friends.

There are several data races that can occur.  Note that these races
are INDEPENDENT of the thread safety of setlocale itself.

1) The attempt to save the old locale can fail.  If thread 1 assigns
to __old, and thread 2 calls setlocale(LC_ALL, "C") before thread 1 is
able to memcpy __old to __sav, thread 1's copy can be corrupted
because the string can be allocated in static storage.

2)  The obvious race between the setting of locale to "C" in thread 1
and thread 2 setting it back to __sav before thread 1 is able to call
functions like strtof, etc.

Any functions that deal with conversions have this problem.

In the past (e.g. PR 6015, 6761, and others), the problems are fixed
on the gnu version but not in the generic side, seemingly due to
(paraphrasing) concentrating on glibc systems.  With respect to c++98,
this seems to be a perfectly valid statement.  (Although the FAQ is
not quite correct in this case, because the FAQ implies that if the C
library is thread safe the C++ library is thread safe, which is not
true due to the data races).

The draft of the c++0x standard, specifically section 17.6.4.8,
prohibits data races introduced on globally visible objects directly
or indirectly by the standard library, which seems to imply that the
behavior of these functions is/will be prohibited.

Before I entered a bug I wanted to see if I am actually interpreting
this correctly.