bug-coreutils
[Top][All Lists]
Advanced

[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.




reply via email to

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