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.
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.
-- Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
