On Fri, Aug 09, 2019 at 07:19:14PM +0200, Jan Stary wrote:
> 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 <= ?
>
> > > 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.)
>
> Jan
>
A way would be to check with Net and FreeBSD to se if they have
anything fixed in that area.
-Otto
