From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30673 invoked by alias); 5 Feb 2007 21:54:44 -0000 Received: (qmail 30646 invoked by uid 48); 5 Feb 2007 21:54:35 -0000 Date: Mon, 05 Feb 2007 21:54:00 -0000 Message-ID: <20070205215435.30645.qmail@sourceware.org> From: "john at thesalmons dot org" To: glibc-bugs@sources.redhat.com In-Reply-To: <20061107172025.3479.hack@watson.ibm.com> References: <20061107172025.3479.hack@watson.ibm.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/3479] Incorrect rounding in strtod() X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2007-02/txt/msg00023.txt.bz2 ------- Additional Comments From john at thesalmons dot org 2007-02-05 21:54 ------- I was not sufficiently clear in Comment #2. The fact that the code prints FAIL in certain cases does not demonstrate whether gcc's literal parser or glibc's strtof is faulty. It only proves that (at least) one of them is failing to adhere to "Recommended Practice" which says they should be the same. HOWEVER, careful inspection of the output, as well as knowledge of how the particular test case was chosen makes it pretty clear that *for this case* gcc is doing the right thing and strtof is at fault. gcc's rounding may not be perfect, but that's not at issue here. The input, "1.00000005960464477550" is the result of printf("%.21g", x) where x = 1 + FLT_EPSILON/2 + LDBL_EPSILON. I.e., it is specifically constructed to be *just a little bit larger* than the mid-point between two representable floats. Correct rounding should be to the larger of the two nearby floats, i.e., 1+FLT_EPSILON. gcc correctly constructs the literal 0x1.00002p0. strof incorrectly returns the value 1.0p0. -- http://sourceware.org/bugzilla/show_bug.cgi?id=3479 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.