libstdc++/6015: 3.1 pre libstdc++ number formatting is not mt-safe.

[Teemu Torma]

On Thu, 2002-03-28 at 23:47, bkoz@gcc.gnu.org wrote:
> Synopsis: 3.1 pre libstdc++ number formatting is not mt-safe.
> 
> State-Changed-From-To: suspended->analyzed
> State-Changed-By: bkoz
> State-Changed-When: Thu Mar 28 14:47:09 2002
> State-Changed-Why:
>     Note that this is not a new problem. Before this, LANG settings that were not "C" would cause input to fail, unconditionally.

This item is not a report about locale handling.  It is about
MT-safeness.  I do not care how locales work with iostreams, as long as
the system works in threaded environment when not using "C" locale.  

I would say the iostreams not being MT safe is a new problem.  Whether
iostreams worked properly with LANG not "C" is a secondary issue.

>     The current code path is not optimal, admittedly. Tricks in the "C" library in the glibc-2.3 timeframe will remove this issue from impacting modern linux systems.

Not optimal?  It is catastrophic and unusable.  Also in our
environments, we do not have any customers in Linux, all in Solaris and
other commercial Unices, so glibc 2.3 will not solve anything.

>     All that is really needed here is some kind of hard-wired "C" locale strtold/sscanf function. Or, some elimination of this step (long threatened by some contributors.)

Agreed.

>     I believe this defficiency can be improved in the future, without breaking the ABI, so this is really not "critical" to me. Can I downgrade this to serios with low priority?

For us, this is critical regression from previous versions.  iostreams
have been working in multi-threaded environments for ages (well, we have
been using it since egcs 1.1). 

Teemu

> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6015