This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/14049] Incorrect strtod, atof etc. hex float rounding
- From: "joseph at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Wed, 02 May 2012 19:23:21 +0000
- Subject: [Bug libc/14049] Incorrect strtod, atof etc. hex float rounding
- Auto-submitted: auto-generated
- References: <bug-14049-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=14049
--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-05-02 19:23:21 UTC ---
Rounding according to the current rounding mode is not part of this issue,
which is about one particular bug in the code addressed by my patch
<http://sourceware.org/ml/libc-alpha/2012-05/msg00076.html>, or of bug
3479 either; it's a separate issue (maybe one without an open bug at
present). In most cases, bugs should cover one limited well-defined
issue, and patches should be incremental and fix the least unit it makes
sense to fix in one patch, so that they are easier to produce and easier
to review (and so a fix for one issue can get in quicker even if there are
problems with the fix for another related issue). It's natural to fix the
bugs with round-to-nearest rounding (hex and decimal separately) before
doing anything about current-rounding-mode rounding.
As discussed for printf in bug 5044, using fegetround would have the
problem that it's only in libm not in libc; although it could be added to
the set of libm functions duplicated in libc, fpu_control.h may be better
but it doesn't have all the relevant macros on all architectures
supporting rounding modes and there's a need for architecture-specific
support for getting rounding modes for cases such as ARM and Power
soft-float.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.