Hello, Michael Kelly, le lun. 13 avril 2026 06:33:13 +0100, a ecrit: > On 13/04/2026 00:01, Samuel Thibault wrote: > > Michael Kelly, le dim. 12 avril 2026 17:49:34 +0100, a ecrit: > > > 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.
Ah, right, of course, negative values are valid. I would then say to use #define MACH_ADJTIME_USECS_OMIT 1000000 #define MACH_ADJTIME_NSECS_OMIT 1000000000 because it is a clear invalid value (more than one second worth of microseconds or nanoseconds), and does not depend on the integer size of the usec/nsec field, and will convert fine between host_adjust_time and host_adjust_time64. > I've assumed all along that it would be unthinkable to alter the mach > interface Yes, so we have to make some invalid values become valid, here 1000000, which happened to have been accepted in the past, but which is usually refused by time functions. Samuel
