From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24181 invoked by alias); 12 May 2007 19:26:45 -0000 Received: (qmail 24147 invoked by uid 48); 12 May 2007 19:26:36 -0000 Date: Sat, 12 May 2007 19:26:00 -0000 Message-ID: <20070512192636.24146.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "pcarlini at suse dot de" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-05/txt/msg00921.txt.bz2 ------- Comment #31 from pcarlini at suse dot de 2007-05-12 20:26 ------- (In reply to comment #30) > 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? Indeed, I was also considering this kind of solution. Excellent. > 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. Fine. Actually, it would have to be an AC_TRY_RUN (we are trying to keep those to a minimum), and I'm just learning to you would have to be rather complex, to be safe. Then, how would we deal with the issue, in practice? _GLIBCXX_HAVE_STRTOLD would still be true on HP-UX, because the function is in any case available at compile time. By way of the _GLIBCXX_HAVE_BROKEN_STRTOLD which I mentioned before? Like: #if defined(_GLIBCXX_HAVE_STRTOLD) && !defined(_GLIBCXX_HAVE_BROKEN_STRTOLD) > I see that at one time we used _GLIBCXX_USE_C99 instead of > _GLIBCXX_HAVE_STRTOLD. However, this caused a problem on mips. I was also considering this option too ;) Too bad we had such kind of problem on mips, because, in principle, it also looks like a conservative solution: that macro results only from TRY_COMPILE tests, but very extensive. I would say it's very-very unlikely that a target passes all the _GLIBCXX_USE_C99 test still such basic functionality of the strto* functions is missing... Anyway, Dave, since you are working hard on the issue (thanks!), I can't consider myself responsible for fixing the problem, for better or worse, I'm unassigning myself from the PR, still in CC and helping of course. -- pcarlini at suse dot de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu | |dot org Status|ASSIGNED |NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836