Op Fri, 09 Aug 2019 19:19:14 +0200 schreef Jan Stary <h...@stare.cz>:
On Jul 31 14:40:42, mailinglists.boudew...@indes.com wrote:
Op Tue, 30 Jul 2019 17:12:56 +0200 schreef <h...@stare.cz>:
> This is what happens on my relatively current
> OpenBSD bbb.stare.cz 6.5 GENERIC#0 armv7 (BeagleBone Black)
> OpenBSD ppc.stare.cz 6.5 GENERIC#0 macppc (an old MacMini)
>
> #include <stdint.h>
> #include <stdio.h>
> #include <math.h>
>
> int
> main()
> {
> long l;
> double d = INT_MAX;
>
> l = lrint(d);
> printf("%f is %ld\n", d, l);
>
> l = lround(d);
> printf("%f is %ld\n", d, l);
>
> return 0;
> }
>
> 2147483647.000000 is -1
> 2147483647.000000 is -1
>
> That doesn't seem right: isn't INT_MAX representable as a long,
> even on these machines where sizeof(int) == sizeof(long)?
If it is less than LONG_MAX, then yes.
Less than, as in strictly less?
Why? Do you mean <= ?
My statement is true for both < and <=, but I guess it would have been
less confusing if I had written "less then or equal to".
> If so, shouldn't lrint(INT_MAX) == INT_MAX = lround(INT_MAX)?
If the double type provides enough mantisse (which I think it does on
all
platforms), and if I read a few C standards correctly, then yes.
> On i386 (an ALIX), I see
>
> 2147483647.000000 is 2147483647
> 2147483647.000000 is -1
>
> so lrint() returns the expected value but lround() does not.
>
> On the amd64s I have, I see the expected:
> 2147483647.000000 is 2147483647
> 2147483647.000000 is 2147483647
>
> Is this a bug or am I missing something obvious?
I'd say it's a bug. Also with a float variable and with lrintf/lroundf
the
outcome should ideally be 2147483647.
OK, how can I help debug this?
(The code in lib/libm/src/*rint*.c seems a bit over my head.)
What Otto said. You could download {Free,Net}BSD code and expand your
program to compare different variants.
--
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
