Sebastian Huber commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1484#note_158980 The direction is right. The limit belongs in the input check, and this branch puts it there. `_Watchdog_Tick()` converts the current CLOCK_REALTIME on every tick, `cpukit/score/src/watchdogtick.c:128`: ```c header = &cpu->Watchdog.Header[ PER_CPU_WATCHDOG_REALTIME ]; first = _Watchdog_Header_first( header ); if ( first != NULL ) { _Timecounter_Getnanotime( &now ); _Watchdog_Tickle( header, first, _Watchdog_Ticks_from_timespec( &now ), ``` `_Watchdog_Ticks_from_timespec()` asserts `!_Watchdog_Is_far_future_timespec( ts )` at `cpukit/include/rtems/score/watchdogimpl.h:552`. A time of day above `WATCHDOG_MAX_SECONDS` therefore breaks every tick which follows the set. A debug build asserts. A release build tickles the realtime collection with a wrapped value for the rest of the run. So `rtems_clock_set()` must reject the year, and a relaxed `_TOD_Set()` cannot repair it. ## `psxclock` fails with this branch `testsuites/psxtests/psxclock/init.c:354` demands `EINVAL` for 13569465601 seconds: ```c puts( "Init: clock_settime - 2400-01-01T00:00:01Z EINVAL" ); tv.tv_sec = 13569465601; tv.tv_nsec = 0; errno = 0; sc = clock_settime( CLOCK_REALTIME, &tv ); rtems_test_assert( sc == -1 ); ``` That value lies below the new constant. `clock_settime()` returns 0 and the assert fails. The case above it prints `2400-01-01T00:00:00.999999999Z` and no longer sits at a boundary. Move both cases and both messages to the new limit. ## The two bounds still disagree `_TOD_Validate()` stops at a year. `_TOD_Is_valid_new_time_of_day()` stops at a second. That gap caused this defect, and the branch keeps it. The notes of `rtems_clock_set()` name `2401-01-01T00:00:00.000000000Z` as the latest value which `clock_settime()` accepts. The check uses `>`, so the true latest value is `2401-01-01T00:00:00.999999999Z`. Close the gap in `cpukit/score/src/coretodcheck.c:54`: ```c if ( tod->tv_sec >= TOD_SECONDS_1970_THROUGH_2400 ) { return STATUS_INVALID_NUMBER; } ``` Both directives then stop at `2400-12-31T23:59:59.999999999Z`. The macro name states an exact fact: a value below the constant lies within 1970 through 2400. The documentation needs one date instead of two. ## `clock.h` states two different limits The branch updates the notes and leaves the constraint list at `cpukit/include/rtems/rtems/clock.h:151`: ``` * - The time of day set by the directive shall be before * 2100-01-01T00:00:00.000000000Z. ``` The file contradicts itself. Both places name the same instant. With the check above: | Place | Text | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | Notes | Due to implementation constraints, the latest time of day which this directive and the POSIX `clock_settime()` accept is 2400-12-31T23:59:59.999999999Z. | | Constraint list | The time of day set by the directive shall be before 2401-01-01T00:00:00.000000000Z. | The new notes text also drops `2401-01-01:00:00.000000000Z`, which is no timestamp. The branch inherited that form from the line it replaced. ## The commit message The body lists the edits which the diff shows. State the problem, then the approach. One point of the list is also wrong: `spclock_err02` holds the leap day check of the year 2400 already, at line 132. The branch keeps that case and replaces the year 2800 case. ## What the branch gets right beyond the direction It drops the year 2800, 4000 and 4095 cases of `spclock_err02`. No directive accepts those years after the change. The value 13601088000 is 2401-01-01T00:00:00Z, and 113.4 years of uptime remain before the 34-bit seconds field wraps. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1484#note_158980 You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/namespace/49/sent_notifications/5-97877m52gbhxnif8bx7sbecp6-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
