On Thu, 21 Dec 2023, Hal Murray wrote:
Let's put that stuff on the back burner until the release is out.
Agreed for OpenBSD per se, though it might be worth trying to determine
whether the apparent fencepost error with OPENSSL_VERSION_NUMBER is really
OpenBSD-specific, or a more general problem that happens to show up here
only in OpenBSD. All the conditionals for it seem to be either '<' or
'>', leaving the '==' case to fall through a crack. Unless the intent is
actually tri-valued behavior, one or the other should include the '=='
case. Admittedly, it's weird that the '==' case seems to want to be
included in the '<' case rather than the '>' case.
I'll probably look into the additional warnings at some point, but not
worry about it until after the release.
Ntpsec doesn't fully support OpenBSD anyway, due to the lack of "timex"
(though my Mac patches fix that), and the fact that OpenBSD provides
LibreSSL rather than OpenSSL, but the 1.2.2a "Mac" version did build with
--disable-nts.
Please say more about your Mac patches?
The patches come in two categories:
Fallback for missing clock_gettime() and clock_settime(). This is fairly
straightforwardly implemented as inlines in ntp_machine.h. Then some
miscellaneous programs that use clock_gettime() and don't include
ntp_machine.h need to be fixed to do so.
Allowing the "timex" stuff to be optional, as it once was. Originally I
just reverted the two commits that caused the problem, but then
subsequently have had to fix conflicts with other changes from time to
time. It could probably be refactored to better localize the relevant
stuff, but fixing the conflicts is always incrementally easier.
The first category would probably be acceptable for inclusion in mainline,
but by itself it doesn't expand the compatibility range. The second
category as it is would probably be too much code clutter.
Does ntpd work?
Yes, it works, except in one weird case that I haven't taken the time to
investigate. In 10.5 x86_64, it builds and passes the tests, but looking
with "ntpq -p", it shows all the initial peers but no actual exchanges
happening. 10.5 ppc and 10.5 i386 work fine, as do all the other cases I
can test.
If I ever get around to fixing that, it will probably suggest some
deficiency in the tests that's probably worth fixing.
Fred Wright
_______________________________________________
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
