Re: "seq .1 .1" would mistakenly generate no output on FreeBSD 6.1

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering pushed for a quick resolution: >> I'm hoping to make a coreutils test release RSN, >> and one of the few things missing is the macro to help >> work around the freebsd 6.1 long double printf bug. > > Your test proggie results revealed that the

Re: "seq .1 .1" would mistakenly generate no output on FreeBSD 6.1

Jim Meyering pushed for a quick resolution: > I'm hoping to make a coreutils test release RSN, > and one of the few things missing is the macro to help > work around the freebsd 6.1 long double printf bug. Your test proggie results revealed that the bug is that although 'long double' generally has

Re: "seq .1 .1" would mistakenly generate no output on FreeBSD 6.1

Come to think of it, aren't the symptoms Jim reported in nearly the opposite of the BeOS symptoms? If I understand things aright, BeOS incorrectly claimed that LDBL_MANT_DIG is 53 when it is actually 64. But FreeBSD has a differ

Re: "seq .1 .1" would mistakenly generate no output on FreeBSD 6.1

Bruno Haible <[EMAIL PROTECTED]> writes: > OK, so let's try a runtime test instead of a compile-time test. OK, but for cross-compilation we need to assume that the bug is absent (contrary to our usual practice for run-time tests), because otherwise cross-compilation will generate the wrong code f

Re: "seq .1 .1" would mistakenly generate no output on FreeBSD 6.1

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> 0.1L == (long double) 0.1 >> evaluates to true. > > OK, so let's try a runtime test instead of a compile-time test. > > What does this program give? > > #include > #include > long double a = 4.0L; > long double b = 5.0L; > int main

Re: "seq .1 .1" would mistakenly generate no output on FreeBSD 6.1

Jim Meyering wrote: > 0.1L == (long double) 0.1 > evaluates to true. OK, so let's try a runtime test instead of a compile-time test. What does this program give? #include #include long double a = 4.0L; long double b = 5.0L; int main() { long double x = a / b; long double y = strtold ("0.8"

Re: "seq .1 .1" would mistakenly generate no output on FreeBSD 6.1

Bruno Haible <[EMAIL PROTECTED]> wrote: > Paul Eggert wrote: >> How about checking for this via a compile-time test? That way we don't >> need to maintain a list of which software systems have the bug. > > Yes, thanks. I wouldn't want to explicitly distinguish FreeBSD 6.1 and 6.2 > in an autoconf

Re: "seq .1 .1" would mistakenly generate no output on FreeBSD 6.1

Paul Eggert wrote: > How about checking for this via a compile-time test? That way we don't > need to maintain a list of which software systems have the bug. Yes, thanks. I wouldn't want to explicitly distinguish FreeBSD 6.1 and 6.2 in an autoconf test. > --- a/lib/float.in.h > +++ b/lib/float.i

Re: "seq .1 .1" would mistakenly generate no output on FreeBSD 6.1

Bruno Haible <[EMAIL PROTECTED]> writes: > the diagnosis is > clear: Bug in . Same as on BeOS. We have a workaround in the > 'float' module. Probably we need to add FreeBSD 6.1 here... How about checking for this via a compile-time test? That way we don't need to maintain a list of which softwar

Re: "seq .1 .1" would mistakenly generate no output on FreeBSD 6.1

me: > > problem with a small test program on FreeBSD/x86 6.1: Oops, that should read: FreeBSD/x86 6.2 Jim, > The value for .8 that produces is not the same as the one > that provokes failure in seq. > > In the above: > (gdb) p x > $1 = 0.80004440892098500626162 > > in seq.c: >

Re: "seq .1 .1" would mistakenly generate no output on FreeBSD 6.1

Paul Eggert wrote: > I guess that the bug lies in the printing of a long double value that > is not exactly representable as a double. This hardly explains it. Jim observes a call scale10_round_decimal_long_double (x, n=1) where x is some valid value. The code of scale10_round_decimal_long_doubl

Re: "seq .1 .1" would mistakenly generate no output on FreeBSD 6.1

Jim Meyering wrote: > It seems to have exposed a problem in gnulib's vasnprintf.c: > > freebsd6$ gdb --args ./seq 0.8 0.1 0.9 > GNU gdb 6.6 > (gdb) r > Starting program: /tmp/coreutils-6.9.89.27-a9805-dirty/src/seq 0.8 0.1 0.9 > 0.8 > Program received signal SIGABRT, Aborted. > 0x281

Re: "seq .1 .1" would mistakenly generate no output on FreeBSD 6.1

Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> It seems to have exposed a problem in gnulib's vasnprintf.c: > > I think this is because the revised (core-dumping) 'seq' is calling > vasnprintf with the equivalent of printf ("%.1Lf", 0.8L), whereas due > to t

Re: "seq .1 .1" would mistakenly generate no output on FreeBSD 6.1

Jim Meyering <[EMAIL PROTECTED]> writes: > It seems to have exposed a problem in gnulib's vasnprintf.c: I think this is because the revised (core-dumping) 'seq' is calling vasnprintf with the equivalent of printf ("%.1Lf", 0.8L), whereas due to the strange compiler settings on FreeBSD the origina

Re: "seq .1 .1" would mistakenly generate no output on FreeBSD 6.1

Paul Eggert <[EMAIL PROTECTED]> wrote: ... > I looked at the revised print_numbers function and found what I think > is one or two other instances of similar problems. I hope the > following code will have a better chance of surviving similar problems > in the future. (The proposed code is a tad