* [Bug libc/17661] printf should output "nan" for some invalid floating point values
2014-11-28 13:55 [Bug libc/17661] New: printf should output "nan" for some invalid floating point values P at draigBrady dot com
@ 2014-11-28 16:49 ` joseph at codesourcery dot com
2014-11-28 17:00 ` P at draigBrady dot com
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: joseph at codesourcery dot com @ 2014-11-28 16:49 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=17661
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
These invalid values are considered trap representations, i.e. undefined
behavior if passed to any glibc function expecting a long double value.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug libc/17661] printf should output "nan" for some invalid floating point values
2014-11-28 13:55 [Bug libc/17661] New: printf should output "nan" for some invalid floating point values P at draigBrady dot com
2014-11-28 16:49 ` [Bug libc/17661] " joseph at codesourcery dot com
@ 2014-11-28 17:00 ` P at draigBrady dot com
2014-11-28 17:21 ` P at draigBrady dot com
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: P at draigBrady dot com @ 2014-11-28 17:00 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=17661
--- Comment #2 from Pádraig Brady <P at draigBrady dot com> ---
Fair enough, but surely "nan" is a better output for these non numbers than the
arbitrary output above?
--
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-26743-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Nov 28 17:06:14 2014
Return-Path: <glibc-bugs-return-26743-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 7163 invoked by alias); 28 Nov 2014 17:06:13 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 6837 invoked by uid 55); 28 Nov 2014 17:06:08 -0000
From: "joseph at codesourcery dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/17661] printf should output "nan" for some invalid floating point values
Date: Fri, 28 Nov 2014 17:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.20
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: joseph at codesourcery dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-17661-131-rmxLkLJTJv@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-17661-131@http.sourceware.org/bugzilla/>
References: <bug-17661-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00235.txt.bz2
Content-length: 591
https://sourceware.org/bugzilla/show_bug.cgi?id\x17661
--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
See
<https://sourceware.org/glibc/wiki/Style_and_Conventions#Error_Handling>
for consensus on handling various erroneous inputs to glibc functions. In
line with that consensus, if anything special is done about such invalid
values (rather than just leaving them to whatever code only considering
valid values happens to produce) then it should abort the program.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug libc/17661] printf should output "nan" for some invalid floating point values
2014-11-28 13:55 [Bug libc/17661] New: printf should output "nan" for some invalid floating point values P at draigBrady dot com
2014-11-28 16:49 ` [Bug libc/17661] " joseph at codesourcery dot com
2014-11-28 17:00 ` P at draigBrady dot com
@ 2014-11-28 17:21 ` P at draigBrady dot com
2014-11-28 17:43 ` joseph at codesourcery dot com
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: P at draigBrady dot com @ 2014-11-28 17:21 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=17661
--- Comment #4 from Pádraig Brady <P at draigBrady dot com> ---
I understand the fail early idea and agree with it in cases like NULL pointers
etc, but not in this case. A lot of these ideas boil down to the same thing,
i.e. not duplicating logic. I.E. not having validation/parsing logic in
multiple places in this case. Given the parsing/validation for this is in
glibc, I think it should handle invalid data gracefully (see vasnprintf in
gnulib for implementation detils). We can at least agree that the output should
be consistent, so should either abort() or return "nan". Returning 1.55 due to
a bit error for example could be catastrophic for a lot of stuff. In bug 4586
we changed from crashing in those cases which I _strongly_ agree with, so along
those lines we should return "nan" for these cases too which user code is
likely already handling.
--
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-26745-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Nov 28 17:21:43 2014
Return-Path: <glibc-bugs-return-26745-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 19613 invoked by alias); 28 Nov 2014 17:21:43 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 19559 invoked by uid 48); 28 Nov 2014 17:21:39 -0000
From: "hjl.tools at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/13862] Reuse of cached stack can cause bounds overrun of thread DTV
Date: Fri, 28 Nov 2014 17:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: 2.21
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: hjl.tools at gmail dot com
X-Bugzilla-Target-Milestone: 2.21
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-13862-131-DDhQK9GEq8@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-13862-131@http.sourceware.org/bugzilla/>
References: <bug-13862-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00237.txt.bz2
Content-length: 505
https://sourceware.org/bugzilla/show_bug.cgi?id\x13862
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #24 from H.J. Lu <hjl.tools at gmail dot com> ---
Fixed for 2.21.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug libc/17661] printf should output "nan" for some invalid floating point values
2014-11-28 13:55 [Bug libc/17661] New: printf should output "nan" for some invalid floating point values P at draigBrady dot com
` (2 preceding siblings ...)
2014-11-28 17:21 ` P at draigBrady dot com
@ 2014-11-28 17:43 ` joseph at codesourcery dot com
2014-11-28 17:59 ` [Bug libc/17661] some invalid floating point values should be considered as "nan" P at draigBrady dot com
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: joseph at codesourcery dot com @ 2014-11-28 17:43 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=17661
--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
But I don't think it's just printf - there are load of libm functions that
examine the bits of a floating-point representation to determine
properties of the value, and consistent handling of these trap
representations would require all those functions to consider them.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug libc/17661] some invalid floating point values should be considered as "nan"
2014-11-28 13:55 [Bug libc/17661] New: printf should output "nan" for some invalid floating point values P at draigBrady dot com
` (3 preceding siblings ...)
2014-11-28 17:43 ` joseph at codesourcery dot com
@ 2014-11-28 17:59 ` P at draigBrady dot com
2014-11-28 18:30 ` joseph at codesourcery dot com
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: P at draigBrady dot com @ 2014-11-28 17:59 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=17661
Pádraig Brady <P at draigBrady dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|printf should output "nan" |some invalid floating point
|for some invalid floating |values should be considered
|point values |as "nan"
--- Comment #6 from Pádraig Brady <P at draigBrady dot com> ---
Aggreed. I adjusted the inaccurate bug summary. The gnulib vasnrintf
implementation depends on an appropriately adjusted isnan() implementation. You
can see the isnan() test comments at:
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=tests/test-isnan.c;h=9cb5e072;hb=HEAD#l189
--
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-26748-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Nov 28 18:17:54 2014
Return-Path: <glibc-bugs-return-26748-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 19192 invoked by alias); 28 Nov 2014 18:17:53 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 19159 invoked by uid 55); 28 Nov 2014 18:17:48 -0000
From: "joseph at codesourcery dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/17661] some invalid floating point values should be considered as "nan"
Date: Fri, 28 Nov 2014 18:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.20
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: joseph at codesourcery dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-17661-131-p3FqdrPAnk@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-17661-131@http.sourceware.org/bugzilla/>
References: <bug-17661-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00240.txt.bz2
Content-length: 928
https://sourceware.org/bugzilla/show_bug.cgi?id\x17661
--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Most libm functions are not using isnan - they generally examine bits of
the representation directly, often in assembly code (and then e.g. select
what to do based on the value of the exponent, assuming that the high
mantissa bit is valid given those exponent bits).
It seems dubious to complicate lots of separate functions for inputs no
valid program will ever pass in. I'm not sure if the logical handling of
the invalid values (i.e. handling consistent with what hardware operations
do) is consistent between x86/x86_64, ia64, m68k either (certainly there
are some differences between the Intel and m68k versions of the format, at
least, which ldbl-96 code needs to allow for in some cases).
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug libc/17661] some invalid floating point values should be considered as "nan"
2014-11-28 13:55 [Bug libc/17661] New: printf should output "nan" for some invalid floating point values P at draigBrady dot com
` (4 preceding siblings ...)
2014-11-28 17:59 ` [Bug libc/17661] some invalid floating point values should be considered as "nan" P at draigBrady dot com
@ 2014-11-28 18:30 ` joseph at codesourcery dot com
2014-11-28 18:41 ` schwab@linux-m68k.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: joseph at codesourcery dot com @ 2014-11-28 18:30 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=17661
--- Comment #8 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Essentially, I think it's a mistake for gnulib to do anything to try to
handle such representations consistently. If a program has a need to
interpret arbitrary bit-patterns as floating-point values without crashing
on any of them, it should pass them explicitly to an appropriate interface
that checks or canonicalizes them, and gnulib could provide such an
interface, but other functions should not attempt such special handling.
Such an interface is probably not TS 18661-1 canonicalizel, since the
representations in question don't correspond to a value of the type and so
don't have a corresponding canonical representation (although maybe that
means canonicalizel should return failure on them). And as iscanonical
takes a value rather than a representation, it's not expected to do
anything meaningful with trap representations either.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug libc/17661] some invalid floating point values should be considered as "nan"
2014-11-28 13:55 [Bug libc/17661] New: printf should output "nan" for some invalid floating point values P at draigBrady dot com
` (5 preceding siblings ...)
2014-11-28 18:30 ` joseph at codesourcery dot com
@ 2014-11-28 18:41 ` schwab@linux-m68k.org
2014-11-29 21:49 ` eblake at redhat dot com
2015-08-24 9:52 ` jsm28 at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: schwab@linux-m68k.org @ 2014-11-28 18:41 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=17661
--- Comment #9 from Andreas Schwab <schwab@linux-m68k.org> ---
The difference of the m68k variant is that it doesn't have any trap
representations. It considers the integer bit as don't-care in Inf and NaN
patterns, and extends the range of normalized numbers by allowing the biased
exponent to become zero.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug libc/17661] some invalid floating point values should be considered as "nan"
2014-11-28 13:55 [Bug libc/17661] New: printf should output "nan" for some invalid floating point values P at draigBrady dot com
` (6 preceding siblings ...)
2014-11-28 18:41 ` schwab@linux-m68k.org
@ 2014-11-29 21:49 ` eblake at redhat dot com
2015-08-24 9:52 ` jsm28 at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: eblake at redhat dot com @ 2014-11-29 21:49 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=17661
Eric Blake <eblake at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |eblake at redhat dot com
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug libc/17661] some invalid floating point values should be considered as "nan"
2014-11-28 13:55 [Bug libc/17661] New: printf should output "nan" for some invalid floating point values P at draigBrady dot com
` (7 preceding siblings ...)
2014-11-29 21:49 ` eblake at redhat dot com
@ 2015-08-24 9:52 ` jsm28 at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jsm28 at gcc dot gnu.org @ 2015-08-24 9:52 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=17661
Joseph Myers <jsm28 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #10 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
As discussed, this is not a bug; glibc only aims that such trap representations
do not cause crashes, not that they are treated consistently as any particular
value. gnulib has been changed to agree:
commit bd38edc81714fc2679b02ef34033f9e15954d32f
Author: Paul Eggert <eggert@cs.ucla.edu>
Date: Fri Feb 20 18:09:47 2015 -0800
printf, isinf, etc.: noncanonical != NaN
Do not require that isinf, printf, etc. treat noncanonical
values as NaNs. Instead, require only that they do not crash.
[...]
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread