Sebastian Huber created an issue: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5538
Assignee: Sebastian Huber It needs to be specified what the limits of `CLOCK_MONOTONIC` should be and what happens if the limit is reached if it can be reached. This clock is also known as the *uptime*. This issue is related to https://users.rtems.org/t/rtems-time-representation-limits-or-rtems-end-of-time/483 which talks about `CLOCK_REALTIME`. The `CLOCK_MONOTONIC` is a clock provided by RTEMS which measures the time since an unspecified starting point. In contrast to `CLOCK_REALTIME`, this clock cannot be set. It may be affected by incremental adjustments for example carried out by the NTP or the use of a PPS signal. The current starting point is one second: ```c static struct timehands th0 = { /* ... */ .th_scale = (uint64_t)-1 / 1000000, .th_offset = { .sec = 1 }, /* ... */ }; ``` Due to performance reasons, a snapshot is also available through this object: ```c #define time_uptime _Timecounter_Time_uptime volatile time_t time_uptime = 1; ``` Declared as: ```c /** * @brief The uptime in seconds. * * For compatibility with the FreeBSD network stack the initial value is one * second. */ extern volatile time_t _Timecounter_Time_uptime; ``` This used to be a 32-bit signed integer for performance reasons, however, it was changed to address a code analysis finding here: #5204. It needs to be clarified what the limits of `CLOCK_MONOTONIC` should be: 1. With a signed 32-bit integer, the uptime is limited to about 68 years. If the system reaches this limit, then the uptime overflows and yields a negative number. In this case, the calculations involving time values are undefined or implementation-defined in C. 2. With an unsigned 32-bit integer, the uptime is limited to about 136 years. If the limit is reached, then modulo arithmetic applies. There are issues, if the time value is assigned to 32-bit singed integer. The libbsd network stack requires a signed integer for `time_uptime`. 3. With a 64-bit integer there are not practical limits. 32-bit targets may have performance issues. 32-bit targets may have correctness issues in the instant the time *t* changes from any time which satisfies `t % (UINT32MAX + 1) == UINT32MAX` to the next value. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5538 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
