[Bug libc/17661] New: printf should output "nan" for some invalid floating point values

[Bug libc/17661] New: printf should output "nan" for some invalid floating point values

[P at draigBrady dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17661

            Bug ID: 17661
           Summary: printf should output "nan" for some invalid floating
                    point values
           Product: glibc
           Version: 2.20
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: P at draigBrady dot com
                CC: drepper.fsp at gmail dot com

Created attachment 7976
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7976&action=edit
test case

With the attached program compiled against glibc or gnulib's vasnprintf() we
get:

  $ sdiff -t -w72 gnulib.out glibc.out
  Pseudo-Infinity                       Pseudo-Infinity
  nan                                |  -0[4911 zeros elided]0.000000
  nan                                |  -0.000000e+4912
  nan                                |  -0e+4912
  Pseudo-Zero                           Pseudo-Zero
  nan                                |  0.000000
  nan                                |  0.000000e+00
  nan                                |  0
  Unnormalized number                   Unnormalized number
  nan                                |  1.550000
  nan                                |  1.550000e+00
  nan                                |  1.55
  Pseudo-Denormal                       Pseudo-Denormal
  nan                                |  0.000000
  nan                                |  8.405258e-4934
  nan                                |  8.40526e-4934

It would be great if glibc would output "nan" also
to greacefully deal with corruption, and so that
gnulib using programs can use the glibc printf functions.

See also bug 4586

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/17661] printf should output "nan" for some invalid floating point values

[joseph at codesourcery dot com]

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.

[Bug libc/17661] printf should output "nan" for some invalid floating point values

[P at draigBrady dot com]

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.

[Bug libc/17661] printf should output "nan" for some invalid floating point values

[P at draigBrady dot com]

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.

[Bug libc/17661] printf should output "nan" for some invalid floating point values

[joseph at codesourcery dot com]

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.

[Bug libc/17661] some invalid floating point values should be considered as "nan"

[P at draigBrady dot com]

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.

[Bug libc/17661] some invalid floating point values should be considered as "nan"

[joseph at codesourcery dot com]

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.

[Bug libc/17661] some invalid floating point values should be considered as "nan"

[schwab@linux-m68k.org]

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.

[Bug libc/17661] some invalid floating point values should be considered as "nan"

[eblake at redhat dot com]

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.

[Bug libc/17661] some invalid floating point values should be considered as "nan"

[jsm28 at gcc dot gnu.org]

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.