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