NetBSD 6.1.5 doesn't have ldexpl in math.h

[Eric S. Raymond]

Fred Wright via devel <devel at ntpsec.org>:
> 
> On Thu, 14 Sep 2017, Eric S. Raymond wrote:
> 
> > So, did I make an ignorant mistake?  Can this fix be rescued?  Is
> > someone else better equipped than me for the rescue?  (Translation:
> > I'd really love to dump this mess on Fred or Gary.)
> 
> The point I was trying to make is that C doesn't promise that long double
> is any better than double, so it should only be used in cases where the
> added precision is "nice to have" rather than mandatory, and where one
> doesn't mind getting platform-specific results from regression tests.

Ahh, OK.  That's much clearer. Now I can think about tradeoffs.

Based on my research, here's what seems to be the case:

1. We are no worse off than before anywhere.   The worst case is it's just
   normal double precision.

2. On x86_64, the usual precision of long double is 80-bit.  In particular
   GCC long double is in the 80-bit camp. So is Mac OS X's.

3. Some BSDs (FreeBSD, OpenBSD) do the bad thing and drop to double precision.

4. Ihaven't been able to find anything definitive about ARM32.

> > OK.  Fred, our convention here is that Mark decides porting scope on
> > considered advice from the senior devs. We treat him as the product
> > strategist even through we're not working inside a corporate structure
> > where that makes obvious sense, simply because he's good at the view
> > from $30Kft and knows where a lot of the corporare bodies are buried.
> > Final decision will be his.
> 
> In an earlier post, Mark stated that he preferred to keep NetBSD6 support
> if possible because it's still recent enough to get security fixes.  If
> the same criterion is applied to OSX, then 10.10 and 10.11 should be
> supported.

I'm absolutely going to count you as a senior dev.  So, you for
retaining, me and Gary for dropping.  Hal and Matt's positions
not known.

Debate still ongoing.  Mark leaning towrds "keep". Noted.

> > I want to ditch the NetBSD 6 and old MacOS shims because they're
> > defect attractors. Mot only that: by visibly compromising on our "C99
> > or GTFO" policy we're legitimizing future exceptions and "It's just
> > one little shim. What harm can it do?" which can come around to bite
> > us in the ass.
> 
> Perhaps, but a piece of code inside a compile-time conditional which is
> false on all platforms considered "important" is extremely unlikely to
> bite a platform considered "important".  It does impact readability,
> though that could be fixed by putting it in a separate source.

That comes under "How can just one little shim hurt?"  Over time the
resulting code bloat and dust in the cracks gets bad. But you know this.

> And strictly speaking, this isn't a "C99" issue. :-)

True. :-)

> > One final point:  I actually think we're in a better position than most
> > projects to be "harsh", as you put it. Security people get it about
> > reducing attack surface; when you're trying to justify snipping off these
> > old warts even though someone is inconvenienced, that's the closest
> > thing you'll ever find to a sovereign excuse.
> 
> A point that often gets missed is that upgrades themselves have a cost in
> that they often break things (especially with Apple).  Forcing someone
> else to upgrade their OS to run your software seems attractive because the
> hassle is Somebody Else's Problem, but that's what Bruce Schneier would
> call an "externalization".

A fair point.  But...on the other hand, a major platform.  Not by our
criterion, which is more or less "Are flocks of these going to be
running in $J_RANDOM_HUMONGOUS_DATACENTER?"  Part of our strategy is
to optimize for the toughest, highest-end users on the newest
hardware.  Classic can keep the hobbyists, we're after the people who
can and sometimes actually do write big donation checks.  We want them
to trust us and love us and give us money and lend us engineers.

That's the world Matt Selsky is seconded to us from; he works for a
high-frequency-trading outfit in New York.

Your attribution to Bruce suggests that you don't know where he picked up the
term, and you are obviously the kind of person who likes to know such things.
So, "Externality" is a term of art in economics:

https://en.wikipedia.org/wiki/Externality
-- 
		<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.