, eh a9b)
# (rh 80, eh a9b)
not ok 1459 - '%a' '2.71828182845904509' -> '0xa.df85458a2bb48p-2' cf
'0xa.df85458a2bb4a9bp-2'
perhaps a bug in our libm?
(I haven't tried this myself, it was just pointed out to me and I hope
for sympathetic ears & coders ;) ).
Thomas
I have two questions for the change below:
> Module Name: src
> Committed By: kamil
> Date: Sat Apr 27 23:04:32 UTC 2019
>
> Modified Files:
> src/distrib/sets/lists/comp: mi
> src/lib/libm: Makefile
> src/lib/libm/man: nextafter.3
in NetBSD libm?
Thank you.
--
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
If people think an upstream is useful, I suggest deleting our libm
completely and replacing it with musl's.
On Fri, Aug 26, 2016 at 10:35:00PM +0900, Rin Okuyama wrote:
> > (1) libm is horribly non-KNF; my understanding is that at one time it
> > had an upstream of sorts which is why it's the way it is, but it
> > doesn't any more so there's no longer any reason to
On 2016/08/26 13:13, David Holland wrote:
(1) libm is horribly non-KNF; my understanding is that at one time it
had an upstream of sorts which is why it's the way it is, but it
doesn't any more so there's no longer any reason to humour this. Is
that correct?
I think so too.
(1) libm is horribly non-KNF; my understanding is that at one time it
had an upstream of sorts which is why it's the way it is, but it
doesn't any more so there's no longer any reason to humour this. Is
that correct?
(2) does anyone who knows floating-point stuff well (which I
