This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
- From: "pcarlini at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 12 Mar 2007 19:51:18 -0000
- Subject: [Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
- References: <bug-31117-9156@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #7 from pcarlini at suse dot de 2007-03-12 19:51 -------
(In reply to comment #6)
> > Anyway, what happens in the GNU systems is that errno is a per-thread variable
> > and the __convert_to_v code has to do nothing special, just safely use it.
>
> I agree. The problem is that this is not happening. __convert_to_v is not
> safely using the per-thread errno. Instead, it is using the global errno.
To be clear, *not* on Linux, right? Because in your report you said Linux and
MacOSX were fine, and that is consistent with my expectations. Indeed, reading
the glibc errno.h it is clear that errno is per-thread.
> The cause is not the __convert_to_v code but something in an include file or a
> gcc option which causes the code to be compiled incorrectly. Yet another file
> in the same library compiled with the same gcc options does access the
> thread-safe errno correctly. That a discrepancy exists indicates a problem
> somewhere.
I have no idea, frankly. Certainly all the sources are compiled with the same
options.
An idea I just had is that maybe we could try to avoid errno completely, at
least in the generic locale model: we could simply check whether the functions
return HUGE_VAL & co. That would mean we can't detect anymore underflows, but
that errno is set on underflows is implementation dependent and, anyway, the
C++ standard mandates that the behavior should be as-if the library used scanf,
which has no notion of underflow. Maybe you can try the change yourself, and
modify __convert_to_v (say the simple one, for double) to check, instead of
errno != ERANGE, d != HUGE_VAL && d != -HUGE_VAL??
One final note: in the forthcoming C++0x standard things will be more tricky
because the C++ library will be able to parse +INF & co, but we should be able
to manage anyway, because we can first detect those and only otherwise, hands
the string to strtod, which then will return HUGE_VAL / -HUGE_VAL only in case
of real overflow (not input of +INF / -INF).
--
pcarlini at suse dot de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117