State of Mac OS support

[Fred Wright]

On Sat, 26 Aug 2017, Eric S. Raymond via devel wrote:

> There have been inquiries from Daniele Nicolodi and Fred Wright about
> Mac OS X support.

Actually, mine wasn't an inquiry, it was an answer. :-)

> Mark Atwood, who's our strategy/product-management/external-relations
> specialist, may override me on this.  Unless and until he does, here's
> the skinny:
>
> <rant>
>
> We're supporting 10.12, which has the POSIX clock calls.  Earlier
> versions can go piss up a rope.

Well, "POSIX" isn't uniquely valued.  For example, some widely available
versions of Linux still require linking with librt for clock_gettime(),
since that wasn't a POSIX call at the time of that glibc version.  Even
OSX 10.5 passed all the POSIX compliance tests for whatever version of
POSIX was in use at the time (and at least at that time, actually passing
POSIX compliance tests was fairly rare).

In general, failing to support OS versions that are supported by classic
NTP isn't a good way to encourage adoption.

> The reason I am vehement about this is that I recently learned a
> thing: some pre-10.12 versions ship with headers that don't match
> what's documented for their releases on the Apple website.

I have no idea WTF you're referring to here.  I know my version, which
mainly just falls back to the *POSIX* gettimeofday()/settimeofday() calls,
at least builds fine for 10.5-10.12, or at least did so until e92a112b8
broke the build for OSX *including 10.12*.

> If Apple can't be bothered to keep its act together enough to present
> a stable and documented API, we can't be bothered to support their
> crap.

Actually they have a stable and documented API which is even "POSIX", just
not the one you were using.  It's called gettimeoday()/settimeofday(). :-)

Even in 10.12, clock_gettime()/clock_settime() offer no operational
advantage over gettimeofday()/settimeofday().  The apparent nanosecond
resolution is an illusion.  Preferring the former makes sense, but falling
back to the latter is perfectly OK (and not even OSX-specific).  The
advice against using gettimeofday()/settimeofday() in the hacking guide is
inapplicable to systems that lack clock_gettime()/clock_settime().

> Yes, we used to ship a special accommodation for Apple's non-POSIX
> calls in 10.11.  At some point it broke.  Given what I learned later -

Aside from whatever you're referring to, the OSX-specific fallback was
*always* functionally broken.  The commonly circulated example for how to
use OSX clock_get_time() has a "port leak" bug (as well as being slower
than it needs to be).  I kept a corrected version of it for
CLOCK_MONOTONIC, though the only place that's used is in ntpfrob (albeit
in a context where it shouldn't be using it).  Of course there are lots of
places that *should* be using CLOCK_MONOTONIC (or better still,
CLOCK_MONOTONIC_RAW), but that's another story.

> including one rumor that their non-POSIX clock-setting call is a no-op
> - I cannot be fscking bothered to figure out *why* it broke.

I have no idea whether clock_set_time() is broken or not, but clearly
settimeofday() works, since classic NTP (both Apple's version and the
MacPorts version) work on OSX <10.12.

Fred Wright