"D. J. Bernstein" wrote on 1998-10-03 02:23 UTC:
Markus Kuhn writes:
Before any arithmetic, you first check whether there is a leap second in one of the arguments and abort if there is (because arithmetic is ill-defined in this case).
Of course, libtai doesn't have that problem.
libtai provides support routines for addition, subtraction, comparison, halving, conversions to and from the external TAI64NA format, and floating-point approximations. Applications don't need to worry about the internal details.
xtime_get can fail
In libtai, tai_now() and taia_now() always succeed.
I think this claim is a bit unrealistic. The only common hardware platform where a correct and robust implementation of your libtai is possible would be a GPS receiver that has been running for at least 12 minutes with an antenna outside a building. I am not sure, what the scope of your API is, but that sounds somewhat restricted to me. I use systems every day that might not know about TAI. You might have defined yourself some sort of synthetic pseudo-TAI that you send through various correction filters and adjust to the real TAI whenever you have correct leap-second tables and an external UTC reference available, but that in the end is not guaranteed to have a reliable relation to the real TAI as published by BIPM/IERS. If it is not TAI, then please do not call it TAI, or be accused of sloppy terminology. If you use some not clearly defined pseudo-TAI, then in the end what you provide is probably just one of the possible implementation forms of xtime's TIME_MONOTONIC, which is also guaranteed to always succeed, but which does not claim to have a relationship with TAI and which can therefore even be implemented on embedded systems with no non-volatile memory whatsoever and with no UTC or TAI reference. The xtime API was designed for a much broader scope and I think is much better suited as a template for an ISO standard. I have looked at your libtai, and the claim that it doesn't have any problems that the xtime API does have certainly does not hold up under even superficial examination. The clock model in your API seems to be a simplistic subset, and regarding the guarantees you make about the availability of TAI it probably either uses misleading terminology or is just not implementable in a robust and reliable way on many platforms. Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>