NetBSD 6.1.5 doesn't have ldexpl in math.h

Fred Wright fw at fwright.net
Fri Sep 15 02:28:17 UTC 2017


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.

> 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 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.

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

> 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".

Fred Wright


More information about the devel mailing list