#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

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

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.12Indefinite
Owner: set to Needs Funding
Status: newassigned

comment:7 Changed on 09/17/18 at 10:15:05 by Sebastian Huber

Component: unspecifiedtool/newlib
Milestone: Indefinite5.1
Resolution: fixed
Status: assignedclosed
Version: 4.104.5

Fixed by #3111.

Note: See TracTickets for help on using tickets.