[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: seq: revert Solaris 8 work-around that caused x86 regression
From: |
Jim Meyering |
Subject: |
Re: seq: revert Solaris 8 work-around that caused x86 regression |
Date: |
Sat, 25 Oct 2008 11:24:09 +0200 |
Paul Eggert <address@hidden> wrote:
> Here's the bug:
>
> $ seq 9223372036854775807 9223372036854775808
> 9223372036854775807
> 9223372036854775808
> 9223372036854775809
>
> This is Debian stable x86, compiled with GCC 4.3.2.
> This worked correctly in older 'seq' versions.
>
> The problem is that the 2008-04-14 seq patch introduced an abs_rel_diff
> function that isn't numerically accurate. I looked into why that
> function was introduced; it was to work around a bug in Solaris 8 and
> some other older systems, where strold ("0.90000000000000000000") <
> strold ("0.9"). We shouldn't worry about working around numeric bugs
> like these in C libraries in older systems, unless the bugs are likely
> to come up in real applications, which is not the case here. Better to
> modify the test case to not tickle the bug in the buggy C library.
Well spotted.
That is definitely an improvement.
I've pushed it, and will add a NEWS entry and a test.
> We can't easily add the above test case, since it's not portable to
> hosts where long double == double.
That hasn't stopped me in the past ;-)
I'm considering a compile-test for e.g.,
int foo[sizeof (long double) - sizeof (double) - 1];
And if that compiles, run your example and require the
correct two lines of output.