Opened on 03/07/16 at 06:39:24
Closed on 09/17/18 at 10:15:05
#2624 closed defect (fixed)
Fix the year 2038 problem
Reported by: | Sebastian Huber | Owned by: | Needs Funding |
---|---|---|---|
Priority: | normal | Milestone: | 5.1 |
Component: | tool/newlib | Version: | 4.5 |
Severity: | normal | Keywords: | |
Cc: | Blocked By: | ||
Blocking: |
Description
RTEMS uses currently a signed 32-bit integer for time_t on Newlib. Thus, it is affected by the year 2038 problem. There are only 22 years left and this time span is within the realistic time frame of some RTEMS applications that are developed now.
The time_t should be changed to int64_t in Newlib. To make sure that all integer operations are carried out properly I suggest to temporarily do this
{{{#include <sys/_stdint.h>
typedef struct {
int64_t _val;
} time_t;
static inline time_t _time_add(time_t a, time_t b)
{
time_t r = { a._val + b._val };
return r;
}
static inline time_t _time_sub(time_t a, time_t b)
{
time_t r = { a._val - b._val };
return r;
}
static inline time_t _time_mul(time_t a, time_t b)
{
time_t r = { a._val * b._val };
return r;
}
static inline time_t _time_div(time_t a, time_t b)
{
time_t r = { a._val / b._val };
return r;
}
}}}
Make sure that RTEMS and Newlib build with this. Add test cases to highlight the time_t integer limits.
Change History (7)
comment:1 Changed on 03/07/16 at 06:59:51 by Nick Withers
comment:2 Changed on 03/07/16 at 07:02:49 by Sebastian Huber
Yes, this is why I wrote temporarily. Once we are reasonably sure that all the integer operations are all right, we use
typedef __int64_t time_t
I am not sure if we should keep the inline functions for clarity.
comment:3 Changed on 03/07/16 at 23:01:46 by Chris Johns
What do you mean by "all integer operations are carried out properly"? How do you decide everything is done properly?
Is this specific to RTEMS and 3rd party code such as gcc and newlib RTEMS depends on?
What happens to code such as cpukit/ftpd/ftpd.c:1193
or cpukit/libfs/src/jffs2/src/fs-rtems.c:1053
? The JFFS has time_t
in it's struct iattr
and I am not sure if this is embedded in the file system in the flash. The RFS has a special type for time in the inode on disk.
comment:4 Changed on 03/07/16 at 23:11:34 by Joel Sherrill
I don't see the value of adding helper methods. Much of the code impacted would have to be altered to use them. Internal code using 64-bit time_t should just work. The issue is where there are interfaces to other representations or storage systems.
Analyse the cases Chris mentions, ask on newlib if there are any known places to be concerned about, and just try it.
Adding use of non-standard helper functions on a standard type is just extra work.
comment:5 Changed on 03/08/16 at 16:58:06 by Sebastian Huber
I didn't assign the ticket to me because I don't work actively on this topic. Its a ticket to collect some ideas.
I just want to point out that its not as simple as "typedef uint64_t time_t".
Joel, how would you ensure that you don't accidentally use maybe a long for time_t arithmetic in Newlib and RTEMS?
comment:6 Changed on 02/15/17 at 14:20:42 by Sebastian Huber
Milestone: | 4.12 → Indefinite |
---|---|
Owner: | set to Needs Funding |
Status: | new → assigned |
comment:7 Changed on 09/17/18 at 10:15:05 by Sebastian Huber
Component: | unspecified → tool/newlib |
---|---|
Milestone: | Indefinite → 5.1 |
Resolution: | → fixed |
Status: | assigned → closed |
Version: | 4.10 → 4.5 |
Fixed by #3111.
time_t 's required to be an integer or floating-point type by POSIX: http://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/types.h.html