[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

["dave at hiauly1 dot hia dot nrc dot ca" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #30 from dave at hiauly1 dot hia dot nrc dot ca  2007-05-12 19:54 -------
Subject: Re:  [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

> Ok, Dave, thanks for the details. Let's go for a configure check, I'll work on
> it.

At the moment, I'm investigating a fix along the lines suggested in
comment #26.  The implementation of strtold in HP-UX 11.11 and earlier
is broken in at least four ways:

1) Return of plus or minus _LDBL_MAX instead of HUGE_VALL if correct
   value would cause overflow,
2) locale support is worse than for sscanf,
3) it is listed by HP as not being thread safe,
4) it doesn't support "inf", "infinite" and "nan" conversions.

As a result of 1, we would have to check errno if we are going to
use strtold.  This is likely not thread safe.  Thus, it looks better
to use sscanf.  I checked.  It returns 0 if the result would cause
overflow.  Is there any reason not to sscanf other than performance?

I sent mail to Steve Ellcey asking him to check the behavior of
strtold in HP-UX 11.23 and 11.31.  If there aren't good technical
reasons to favor strtold over sscanf, I think we had best go for
consistency on all versions of HP-UX.  In that case, we wouldn't
need the configure check.

I see that at one time we used _GLIBCXX_USE_C99 instead of
_GLIBCXX_HAVE_STRTOLD.  However, this caused a problem on mips.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836