[RTEMS Project] #4338: rtems_clock_set(): Cannot set future dates later than approximately 2105
RTEMS trac
trac at rtems.org
Wed Apr 21 05:19:03 UTC 2021
#4338: rtems_clock_set(): Cannot set future dates later than approximately 2105
-------------------------------------------------+-------------------------
Reporter: Frank Kuehndel | Owner: Sebastian
| Huber
Type: defect | Status: assigned
Priority: normal | Milestone: 6.1
Component: rtems | Version: 6
Severity: normal | Resolution:
Keywords: rtems_clock_set, 2514, | Blocked By:
_TOD_To_seconds |
Blocking: |
-------------------------------------------------+-------------------------
Comment (by Frank Kühndel <frank.kuehndel@…>):
In [changeset:"7bbbe4225c92b646faa14e5f5800ed2feba09899/rtems"
7bbbe42/rtems]:
{{{
#!CommitTicketReference repository="rtems"
revision="7bbbe4225c92b646faa14e5f5800ed2feba09899"
clock:_TOD_To_seconds(): Fix year 2514 overflow
This patch fixes issue #4338 by changing _TOD_Validate()
to only accept years till 2105. This requires another patch
to change the documentation of rtems_clock_set() and other
affected API functions (indicating the end date is 2105 not 2514).
I tried to support till year 2514 but it turned out that
this needs changing the Timer Manager too. That in turn
would mean to change _TOD_Seconds_since_epoch( void )
from 32 to 64 bit. Sebastian pointed out that a naive extension
leads to trouble with 32 bit processors. He deemed a safe
re-implementation too costly performance wise considering
that year 2106 is far away and current binaries using RTEMS
Classic API are unlikely to be in use by 2106.
The constant TOD_SECONDS_AT_2100_03_01_00_00 in
cpukit/rtems/src/clocktodtoseconds.c happens to be wrong by
1 hour. When setting the date 2100-Feb-28 23:59:59 and then
reading the date again you will find yourself in 2100-Feb-27.
Update #4338
}}}
--
Ticket URL: <http://devel.rtems.org/ticket/4338#comment:5>
RTEMS Project <http://www.rtems.org/>
RTEMS Project
More information about the bugs
mailing list