diff options
| author | Frank Kühndel <frank.kuehndel@embedded-brains.de> | 2021-04-08 15:41:15 +0200 |
|---|---|---|
| committer | Sebastian Huber <sebastian.huber@embedded-brains.de> | 2021-04-21 07:13:31 +0200 |
| commit | 7bbbe4225c92b646faa14e5f5800ed2feba09899 (patch) | |
| tree | ece4e7cd78885c29207ce0b2c50ea537af65bc86 /cpukit/rtems/src/clocktodvalidate.c | |
| parent | bsps/arm: Set MSP in ARMv7-M start code (diff) | |
| download | rtems-7bbbe4225c92b646faa14e5f5800ed2feba09899.tar.bz2 | |
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
Diffstat (limited to '')
| -rw-r--r-- | cpukit/rtems/src/clocktodvalidate.c | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/cpukit/rtems/src/clocktodvalidate.c b/cpukit/rtems/src/clocktodvalidate.c index d8af275d04..2685bfd6e7 100644 --- a/cpukit/rtems/src/clocktodvalidate.c +++ b/cpukit/rtems/src/clocktodvalidate.c @@ -52,6 +52,7 @@ bool _TOD_Validate( (the_tod->month == 0) || (the_tod->month > TOD_MONTHS_PER_YEAR) || (the_tod->year < TOD_BASE_YEAR) || + (the_tod->year > TOD_LATEST_YEAR) || (the_tod->day == 0) ) return false; |