Re: isnanl, printf, and non-IEEE values

On 06/19/2012 05:51 AM, John Spencer wrote: > #ifdef SYS_USES_LD80 > x = get_valid_ld80_or_zero(x); > #endif > > OSLT. why should i care ? go figure it out yourself. As I understand it, it was your assertion that code like GNU od's could be written portably, using standard C. I was merely trying

Re: isnanl, printf, and non-IEEE values

Eric Blake wrote: > On 06/19/2012 06:51 AM, John Spencer wrote: >> *sigh*. >> talking to you guys is like talking to a wall. > > Please don't swear. This is a publicly archived list, and you are > coming across rather offensive. A positive attitude is more likely to > foster cooperation than bera

Re: isnanl, printf, and non-IEEE values

On 06/19/2012 06:51 AM, John Spencer wrote: > *sigh*. > talking to you guys is like talking to a wall. Please don't swear. This is a publicly archived list, and you are coming across rather offensive. A positive attitude is more likely to foster cooperation than berating others. >> There's no f

Re: isnanl, printf, and non-IEEE values

*sigh*. talking to you guys is like talking to a wall. seriously, with your attitude you will render GNU a complete joke in less than a decade, even moreso than it is already. unfortunately that will also affect the FSF. On 06/19/2012 04:37 AM, Paul Eggert wrote: On 06/18/2012 06:27 PM, John S

Re: isnanl, printf, and non-IEEE values

On 06/18/2012 06:27 PM, John Spencer wrote: > easy: add a check for the invalid LD bit representations How does one do that, exactly? I thought the whole point of the proposed exercise was that code must be portable to any standard C implementation. So, where's the portable code to do what you're

Re: isnanl, printf, and non-IEEE values

On 06/19/2012 04:00 AM, Eric Blake wrote: On 06/18/2012 07:27 PM, John Spencer wrote: It's nice to be able to print a floating point value retrieved from a file, even if the file got messed up somehow, ack. That argues that printf() should be robust to _everything_ you throw at it, even bit p

Re: isnanl, printf, and non-IEEE values

On 06/18/2012 07:27 PM, John Spencer wrote: >> It's nice to be >> able to print a floating point value retrieved from a file, >> even if the file got messed up somehow, > ack. That argues that printf() should be robust to _everything_ you throw at it, even bit patterns that are not produced by ar

Re: isnanl, printf, and non-IEEE values

On 06/19/2012 01:15 AM, Paul Eggert wrote: On 06/18/2012 05:07 AM, John Spencer wrote: it was already discussed that "GNU od" does, but it can be easily fixed there. I don't see how. easy: add a check for the invalid LD bit representations in ldtoastr() in gnulibs ftoastr.c. since it was writ

Re: isnanl, printf, and non-IEEE values

On 06/18/2012 05:07 AM, John Spencer wrote: > it was already discussed that "GNU od" does, > but it can be easily fixed there. I don't see how. And even if it could be, why not just leave things as they are? It's nice to be able to print a floating point value retrieved from a file, even if the

Re: isnanl, printf, and non-IEEE values

Rich Felker writes: > On Mon, Jun 18, 2012 at 10:21:34AM -0700, Ben Pfaff wrote: >> Bruno Haible writes: >> >> > 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 o

Re: isnanl, printf, and non-IEEE values

On Mon, Jun 18, 2012 at 10:21:34AM -0700, Ben Pfaff wrote: > Bruno Haible writes: > > > 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 float

Re: isnanl, printf, and non-IEEE values

Bruno Haible writes: > 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. That's an interesting point. GNU PSPP reads unco

Re: isnanl, printf, and non-IEEE values

On 06/18/2012 03:06 PM, Bruno Haible wrote: John Spencer wrote: its not the job of the libc to make broken code happy. i dont think its a good idea to make thousands of correct programs slower, just that GNU guys dont have to fix one program. Following your argumentation, we don't need - W^

Re: isnanl, printf, and non-IEEE values

John Spencer wrote: > its not the job of the libc to make broken code happy. > > i dont think its a good idea to make thousands of correct programs slower, > just that GNU guys dont have to fix one program. Following your argumentation, we don't need - W^X protection in the x86 hardware, - ad

Re: isnanl, printf, and non-IEEE values

onSun, 17 Jun 2012 16:00:13 -0700 Paul Eggert wrote On 06/17/2012 03:41 PM, Rich Felker wrote: No program I know of reads long double directly from binary files. 'od -tfL' does. it was already discussed that "GNU od" does, but it can be easily fixed there. its not the job of the libc to

Re: isnanl, printf, and non-IEEE values

Rich Felker wrote: > > > 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. > >

Re: isnanl, printf, and non-IEEE values

On 06/17/2012 03:41 PM, Rich Felker wrote: > No program I know of reads long double directly from binary files. 'od -tfL' does. I'm sure there are others. It's pretty common to save binary data into files and restore it later.

Re: isnanl, printf, and non-IEEE values

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: > >

Re: isnanl, printf, and non-IEEE values

Rich Felker wrote: > > > 2. Several tests for isnanl and printf long double support are > > > invalid. They are generating invalid LD80 representations that cannot > > > occur as values ("pseudo-denormal", for example) and testing that > > > isnanl and printf treat these as NAN. Per the C standard,