NetBSD 6.1.5 doesn't have ldexpl in math.h

[Fred Wright]

On Wed, 13 Sep 2017, Hal Murray via devel wrote:

> I think the whole doubletime_t was a wild goose chase.
>
> The claimed reason was precision.  A double has 53 bits.  We are interrested
> in adjustments, not absolute values.  If we are taking a huge adjustment (31
> bits), that still leaves 20 bits of fractional second.  That's microseconds.
> I think that's good enough to get started.  Most adjustments are small
> fractions of a second.  If we start with 53 bits, we will be throwing away
> almost half of them when we convert to l_fp.

Indeed.  For time *deltas*, ordinary double precision is perfectly
adequate.  E.g., a one-hour delta has sub-picosecond precision, a one-week
delta has sub-nanosecond precison, etc.  If your clock is off by a month
and you're worrying about nanoseconds, then you're misguided. :-)

Ordinary doubles are indeed inadequate for "absolute" time values (i.e.
values relative to any plausible epoch).  But long doubles don't fix this,
because the C language doesn't really take them seriously, and doesn't
guarantee that they differ from standard doubles at all.  If you *need*
precision beyond a double, your only portable recourse is to avoid
floating-point altogether.

To put it another way, in order to use long doubles, you need to:

1) Accept that you only get extra precison opportunistically, as a
function of the platform (possibly no extra precision at all).

2) Accept that when the added precision *is* available, all related
operations will be significantly slower.

3) Either give up on regression testing, or make said testing explicitly
platform-specific.

IMO, if a proper cost-benefit analysis of the use of long doubles in the
NTP context were conducted, it would result in a resounding thumbs down.

On Wed, 13 Sep 2017, Eric S. Raymond via devel wrote:

> Mark: Rolling our own lldexp is getting into the territory of "really
> bad ideas that raise the hair on my neck".

Well, the underlying bad idea is using long doubles at all. :-) Once one
doesn't do that, the issue is moot.

On Wed, 13 Sep 2017, Mark Atwood via devel wrote:

> It doesnt even have to be fully generic, just if NetBSD6 etc.  If a BSD is
> still supported by it's community, I'm not happy about dropping it.

All the fuss over long doubles has distracted folks from a more legitimate
issue with NetBSD 6.1.5, which is that python-config returns a nonworking
build setup for the C extension.  But a workaround should be possible, and
it's only in the build procedure, not the code.

On Wed, 13 Sep 2017, Eric S. Raymond via devel wrote:

> Mark Atwood via devel <devel at ntpsec.org>:
> > NetBSD6 still supported, so it's still running in the wild.
> >
> > I know we've been removed most compatibility shims, but are they all gone?
> >   or do we still have a chunk of "if this OS, then define these missing
> > functions"?
>
> I think the last OS-related shim where we define substitute code is gone.
> It was the kludge for pre-10.12 Mac OS X, which turned out not to work because
> (a) in some versions the system headers didn't match the docs, and (b) we got
> a report that in some versions the set-time primitive doesn't work.

Well, *that* fallback code was broken in multiple ways, anyway, as was the
comparable code in GPSD before I fixed it.  With *correct* fallback code,
(a) and (b) are both inapplicable.

Limiting support to a OS version that's not even a year old is rather
heavy-handed, especially when there isn't a really good reason for it.
And the same fallback that works for 10.11 works at least as far back as
10.5 (all of which are supported by classic ntpd, BTW).

MR coming, now that I've tested the code on 10 different "machines".  Now
I can get back to fixing the multitude of Python library issues.

Fred Wright