Y2038 bug on embedded platform

Started by pozz August 23, 2017
I'm using <time.h> facilities to manage timestamps of events. The 
platform is ARM Cortex-M3 (LPC1788) and I'm using MCUXpresso IDE (so 
arm-gcc toolchain). I configured the IDE to use newlib-nano library.

It's quite easy to use a time_t variable for a timestamp and use 
gmtime()/mktime() function to transform the number of seconds from epoch 
to a broken-down time structure (struct tm, with hours, days, ...)

However I noticed time_t is a 32-bit signed integer type... so it can't 
be used to store timestamps over year 2038 (only 21 years remains).

Is there a simple solution to force time_t to be a 64-bit integer?

avr-libc uses another "non-standard" approach. time_t is always 32-bits, 
but the epoch is year 2000 (not 1970). So the year of the bug is thirty 
years later than 2038.
Op Wed, 23 Aug 2017 16:29:39 +0200 schreef pozz <pozzugno@gmail.com>:
> Is there a simple solution to force time_t to be a 64-bit integer?
newlib/libc/include/machine/types.h -#define _TIME_T_ long /* time() */ -#define _TIME_T_ long long /* time() */ -- (Remove the obvious prefix to reply privately.) Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
Il 23/08/2017 17:30, Boudewijn Dijkstra ha scritto:
> Op Wed, 23 Aug 2017 16:29:39 +0200 schreef pozz <pozzugno@gmail.com>: >> Is there a simple solution to force time_t to be a 64-bit integer? > > newlib/libc/include/machine/types.h > -#define&#2013266080;&#2013266080;&#2013266080;
_TIME_T_&#2013266080;&#2013266080;&#2013266080; long&#2013266080;&#2013266080;&#2013266080;&#2013266080;&#2013266080;&#2013266080;&#2013266080;&#2013266080;&#2013266080;&#2013266080;&#2013266080; /* time() */
> -#define&#2013266080;&#2013266080;&#2013266080;
_TIME_T_&#2013266080;&#2013266080;&#2013266080; long long&#2013266080;&#2013266080;&#2013266080;&#2013266080;&#2013266080;&#2013266080;&#2013266080; /* time() */ Do you mean to change the .h file where time_t is defined? I think I need to recompile the C libraries... at lest. I'm sure it will be a complex job for me. However the definition of _TIME_T_ on my PC is in C:\nxp\MCUXpressoIDE_10.0.2_411\ide\tools\arm-none-eabi\include\sys\_types.h I also checked the sources in the git repository and _TIME_T_ is defined in newlib/libc/include/sys/_types.h [1] [1] https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob_plain;f=newlib/libc/include/sys/_types.h;hb=HEAD
Op Thu, 24 Aug 2017 09:18:42 +0200 schreef pozz <pozzugno@gmail.com>:
> Il 23/08/2017 17:30, Boudewijn Dijkstra ha scritto: >> Op Wed, 23 Aug 2017 16:29:39 +0200 schreef pozz <pozzugno@gmail.com>: >>> Is there a simple solution to force time_t to be a 64-bit integer? >> newlib/libc/include/machine/types.h >> -#define _TIME_T_ long /* time() */ >> -#define _TIME_T_ long long /* time() */ > > Do you mean to change the .h file where time_t is defined?
Yes.
> I think I need to recompile the C libraries... at lest.
Yes. And install it somewhere including the new set of header files.
> I'm sure it will be a complex job for me.
If it is, then the IDE and/or library makers have done a bad job.
> However the definition of _TIME_T_ on my PC is in > > C:\nxp\MCUXpressoIDE_10.0.2_411\ide\tools\arm-none-eabi\include\sys\_types.h > > I also checked the sources in the git repository and _TIME_T_ is defined > in newlib/libc/include/sys/_types.h [1] > > [1] >
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob_plain;f=newlib/libc/include/sys/_types.h;hb=HEAD Then I guess I looked at a different version of newlib-nano. -- (Remove the obvious prefix to reply privately.) Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/