Thanks for the reply Richard! Agree, this is just a short-term workaround. Maybe we can add _TIME_BITS=64 in our makefile for all? https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
-----Original Message----- From: Richard Cochran <[email protected]> Sent: Thursday, May 9, 2019 7:13 AM To: Vincent Li X <[email protected]> Cc: [email protected] Subject: Re: [Linuxptp-devel] Year 2038 problem on 32-bit machine On Tue, Apr 23, 2019 at 05:25:54PM +0000, Vincent Li X wrote: > We realized on our machine, the timespec.time_t (long int) is of 4 bytes, > which would cause overflow when converting to internal tmv_t, if the second > value is bigger than 2pow(31)-1. > https://en.wikipedia.org/wiki/Year_2038_problem > > How do we solve this problem in general? You will have to re-compile your 32 userland with a new gnu libc. > Would below conversion to unsigned is a proper fix? No, that doesn't help at all. > diff --git a/tmv.h b/tmv.h > index cca4da7..2e34ff4 100644 > --- a/tmv.h > +++ b/tmv.h > @@ -139,7 +139,7 @@ static inline struct Timestamp > tmv_to_Timestamp(tmv_t x) static inline tmv_t timespec_to_tmv(struct > timespec ts) { > tmv_t t; > - t.ns = ts.tv_sec * NS_PER_SEC + ts.tv_nsec; > + t.ns = (unsigned long int)ts.tv_sec * NS_PER_SEC + ts.tv_nsec; > return t; > } Just casting doesn't magically add the missing bits! Sorry, Richard _______________________________________________ Linuxptp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
