RE: [Nolug] Year 2038 Problem

Hi Jimmy.

Not bad. I believe that he got one thing wrong, however. Yes, it is a 32 bit
signed integer. No, it did not start at -2B. It started at 0.

Thanks,

John

    John Souvestre - New Orleans LA

-----Original Message-----
From: owner-nolug@stoney.kellynet.org [mailto:owner-nolug@stoney.kellynet.org]
On Behalf Of Jimmy Hess
Sent: Mon, May 19, 2014 8:03 pm
To: nolug@nolug.org
Subject: Re: [Nolug] Year 2038 Problem

On Mon, May 19, 2014 at 7:34 PM, John Souvestre <johns@sstar.com> wrote:
> Hi guys.

The numberphile folks put together a nice little video:
http://numberphile.com/videos/unix_time.html

Even as newer versions of Linux have moved time_t to 64-bit.....
matters are a bit more complicated than just having language-level issues fixed.

PHP may be fixed, but there could still be PHP code that works today
by coincidence, which will stop working after 2038, because
datatypes and assumptions were made that rely on the 'utc seconds'
number lying within a certain numerical range or string length
Yeah... i've seen ugly code where a UTC number was stored in an INT
or a VARCHAR(10).

(1) NTP....
What does the code look like to request the current time from a NTP server?
Well, a naive client implementation might ignore rollovers or
other features of NTP (Because the code's worked fine for 50 years
or so... the bugs were never found) and may well look something like this.....
     unsigned char sendbuf[48]={010,0,0,0,0,0,0,0,0};
      int currentTime;

         if ( sendto(s, sendbuf, sizeof(sendbuf), 0, (struct sockaddr
*)&addr,sizeof(addr)) < 0 ) { /* error */ } else
         if ( recv(s, buffer,sizeof(buffer),0) >= 11 ) {
             currentTime = ntohl(((int*)buffer)[10]);
             currentTime -= 2208988800U;
         }
        /* currentTime is the current UTC timestamp */

       /* Ignoring that the NTP timescale rolls over in 2036 for the first
time... uses a 32-bit seconds value and a 32-bit fracseconds value combined
with an Era number and Era offset */

(2) SSL certificates.... This is not necessarily a problem in the
X509 ASN itself... last I checked, in 32-bit versions of OpenSSL the valid
until date overflows... expiration date beyond 2038 gets interpreted as a date
before 1970.

(3) Tens of thousands of C programs that use 'signed int' instead of 'time_t'.
* In a similar manner to how there are lots of C programs still representing an
IP address as a 32-bit int, without even bothering with 'struct in_addr'; good
luck with IPv6.

(4) C programs that pack a 32-bit value into a struct and write binary
structs to disk; change the datatype, and suddenly the program's
datafile can no longer be read and... then the data file needs some kind of
migration mechanism to be designed.

(5) MySQL, GDBM ,BerkeleyDB database tables that may use int to represent a
utc seconds value; SQL internal data representations, including on-disk storage
format.

--
-JH
___________________
Nolug mailing list
nolug@nolug.org

___________________
Nolug mailing list
nolug@nolug.org