Regression in OpenBSD

[Fred Wright]

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