std::moneypunct and std::numpunct implementations are not thread-safe

                 Key: STDCXX-1056
             Project: C++ Standard Library
          Issue Type: Bug
          Components: 22. Localization
    Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
         Environment: Solaris 10 and 11, RedHat and OpenSuSE Linux, Sun C++ 
Compilers 12.1, 12.2, 12.3
Issue is independent of platform and/or compiler.
            Reporter: Stefan Teleman
             Fix For: 4.2.x, 4.3.x, 5.0.0

several member functions in std::moneypunct<> and std::numpunct<> return
a std::string by value (as required by the Standard). The implication of 
being that the caller "owns" the returned object.

In the stdcxx implementation, the std::basic_string copy constructor uses a 
underlying buffer implementation. This shared buffer creates the first problem 
these classes: although the std::string object returned by value *appears* to 
be owned
by the caller, it is, in fact, not.

In a mult-threaded environment, this underlying shared buffer can be 
subsequently modified by a different thread than the one who made the initial 
call. Furthermore, two or more different threads can access the same shared 
buffer at the same time, and modify it, resulting in undefined run-time 

The cure for this defect has two parts:

1. the member functions in question must truly return a copy by avoiding a call 
to the copy constructor, and using a constructor which creates a deep copy of 
the std::string.

2. access to these member functions must be serialized, in order to guarantee 
of the creation of the std::string being returned by value.

Patch for 4.2.1 to follow.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


Reply via email to