NetBSD 6.1.5 doesn't have ldexpl in math.h

[Mark Atwood]

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 at ntpsec.org>
wrote:

> Gary E. Miller via devel <devel at ntpsec.org>:
> > Yo Mark!
> >
> > On Wed, 13 Sep 2017 23:15:10 +0000
> > Mark Atwood <fallenpegasus at 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 at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel

-- 

Mark Atwood
http://about.me/markatwood
+1-206-604-2198 Mobile & Signal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170914/e28c9cad/attachment.html>