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 _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
