bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: isnanl, printf, and non-IEEE values


From: Rich Felker
Subject: Re: isnanl, printf, and non-IEEE values
Date: Sun, 17 Jun 2012 18:41:14 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Jun 17, 2012 at 11:33:45PM +0200, Bruno Haible wrote:
> The other justification for handling these representations was brought up
> by Jim in the long thread that surrounded this glibc bug:
> <http://sourceware.org/bugzilla/show_bug.cgi?id=4586>
> <http://sourceware.org/ml/libc-alpha/2007-06/msg00001.html>
> See also the summary in
> <http://lists.gnu.org/archive/html/bug-gnulib/2007-09/msg00105.html>.
> 
> Namely, glibc was not only producing wrong output. glibc *crashed* when
> you passed some floating-point value outside the IEEE range. Jim's

This happened to our implementation too at one point, and it
definitely has me considering just supporting the damn things... I'm
not all that opposed to it, but my main interest in having the
discussion over gnulib is that I believe gnulib should not demand that
implementations make this choice and consider failure to do so grounds
for replacing printf (which could have lots of unwanted side effects).

> argument: A program can produce floating-point values from a multitude of
> sources; one way is to read them binary-encoded from files.
> 
> In theory you would be right that data should be validated at the boundaries
> of the program, that is, when they are read from outside sources. But no
> program I know of does this for unconstrained floating-point numbers. Hence,

No program I know of reads long double directly from binary files.
Doing so would be inadvisible for many reasons - the existance of
invalid bit patterns, the inherent non-portability of the format, and
the possibility of information leakage from storing a data type with
padding bits (which ld80 has on x86 and x86_64) directly to disk.

> the easiest way to avoid programs from crashing or producing senseless
> output is to treat non-IEEE values like NaNs. This is what we're doing in
> gnulib.
> 
> > So isnanl is expected to be slower in every program that's using it
> > for legitimate arithmetic purposes
> 
> Yes. But it will not be slower by much. The CPUs have an instruction for
> 'fpclassify'; you just need to pass the right bitmask to that instruction.

Are you sure that's faster than avoiding loading the value into the
fpu at all and doing integer arithmetic/bit tests? I have my doubts.

> > for the sake of one program's ease
> > of implementing a non-standard and mostly useless feature?
> 
> The ability to call printf on a 'long double' argument without risking a
> crash is a "mostly useless feature"? Some people see it differently.

I see coddling hypothetical incorrect programs that probably don't
even exist as a mostly-useless feature.

> > Attempting to replace "big" functions like printf should be avoided
> > unless absolutely necessary.
> 
> Have you seen how broken printf is on many systems?
> <http://www.gnu.org/software/gnulib/manual/html_node/printf.html>

Please add glibc to the list:
http://sourceware.org/bugzilla/show_bug.cgi?id=6530

Another report of the issue is here (#1 under glibc bugs):
http://www.kernel.org/pub/linux/libs/uclibc/Glibc_vs_uClibc_Differences.txt

Rich



reply via email to

[Prev in Thread] Current Thread [Next in Thread]