Hi Samuel,
On 13/04/2026 00:01, Samuel Thibault wrote:
Hello,
Michael Kelly, le dim. 12 avril 2026 17:49:34 +0100, a ecrit:
1) Changes to gnumach:
1a) Addition of a constant MACH_ADJTIME_SECS_MAX. This value is close
to the largest number of seconds that can be managed with
host_adjust_time64(). (2145 is (was?) supported on Linux so I
specified that rather than a theoretical 2146).
This looks odd. Better just define MACH_ADJTIME_SECS_OMIT ((long_integer_t)-1)
1b) Alteration to host_adjust_time64() to disregard the new delta when
it is outside the permitted range but still return KERN_SUCCESS so
that the old delta can be retrieved.
Letting bogus parameters go unnoticed is also not a good thing. Really
better return KERN_INVALID_ARGUMENT when the argument is invalid (not
valid value and not MACH_ADJTIME_SECS_OMIT).
I think it will turn out that you are right and that I'm
misunderstanding something but I can't understand how we can use -1 as
the number of seconds. It's permissible to specify a positive or a
negative 'new_adjustment' and -1 falls within the valid range. The
fundamental problem is that host_adjust_time64() takes a mandatory
'new_adjustment' parameter rather than being optional as required by
adjtime(). I've assumed all along that it would be unthinkable to alter
the mach interface so there needs to be some other method of indicating
to host_adjust_time functions that 'new_adjustment' is not actually to
be used and hence acceptance of the bogus parameter. This is why I
wondered right at the start if a new interface wasn't required so that
this kludge wouldn't be needed.
Please point out my mistake so I can get this task cleared up and move on.
Cheers,
Mike.
