Fair enough. We should still feed a bug report to NetBSD6, maybe one of their FP guys will patch it in. And we drop NetBSD6 now, because of that lack.
..m On Wed, Sep 13, 2017 at 5:52 PM Eric S. Raymond via devel <devel@ntpsec.org> wrote: > Gary E. Miller via devel <devel@ntpsec.org>: > > Yo Mark! > > > > On Wed, 13 Sep 2017 23:15:10 +0000 > > Mark Atwood <fallenpega...@gmail.com> wrote: > > > > > We could just grab from NetBSD7. > > > > Nope, that is very low level FPU assembly code. Very arch dependent. > > Usually buried deep in the C compiler as a builtin. > > > > Just look at gcc for all the arch options it has for floating point! > > > > > Or if we know it's an IEEE754 > > > float, just do the direct bit ops. > > > > Sort of a float, it is a long double. The IEEE754 does not specify how > > big in memory a long double is. It may be 80 bits, or 128 bits, or? > > > > IEEE754 also does not specify how the bits are arranged in memory. > > > > > Or the direct fp cpu op. > > > > Assuming you even have a long double FPU. Remember this has to > > support various, ARM, i386, amd64, MIPS, sparc, etc. you may not even > > have any FPU. > > Mark: Rolling our own lldexp is getting into the territory of "really > bad ideas that raise the hair on my neck". > > The reason I'm getting that feeling is that lldexp is unlike - say - > strlcpy > in an important way. Floating-point code is a *notorious* defect > attractor. > It's infamously difficult to even test it in a way that catches all its > edge > cases, especially cross-architecture. > > I can all too easily see us committing to this, then spending an > amount of maintainence effort that diverges to infinity on code that > is never quite right, constantly delivering a trickle of unpleasant > low-level surprises. > > In principle, things could be different. If we had a dev with a strong > background in FP code and numerical analysis (say, as strong in that > domain as Daniel is in security/crypto), I might consider a homebrew > emulation a risk worth taking for an OS version that is minor-platform > and aging out rapidly. > > As it is, give the team we have, I'm going to strongly recommend not going > there. We're good, but we're no good enough at *this*. > -- > <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> > > My work is funded by the Internet Civil Engineering Institute: > https://icei.org > Please visit their site and donate: the civilization you save might be > your own. > > > _______________________________________________ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel -- Mark Atwood http://about.me/markatwood +1-206-604-2198 Mobile & Signal
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
