year 9223372034708485227 problem

Pavel Machek
2004-09-22T21:30:44Z

Hi!

For testing (read() and write() is returning wrong value on 2.4
kernels) I played a bit with really big numbers... And I found out we
have year 9223372034708485227 problem ;-).

hobit:/tmp # cat 2gbtime.c

/**************************** 2gbwrite.c **************************/
#define _SVID_SOURCE /* glibc2 needs this */
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <values.h>
#include <malloc.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>
#include <time.h>

int main(int argc, char **argv)
{
long t = 0x7fffffff80123456;
stime(&t);
printf("It is now: %lx\n", time(NULL));
}
/*********************** end of 2gbwrite.c *************************/
hobit:/tmp # ./2gbtime
It is now: 7fffffff80123456
hobit:/tmp # date
Segmentation fault
hobit:/tmp # top
Segmentation fault
hobit:/tmp # mc
Segmentation fault
hobit:/tmp # /sbin//shutdown -r now
Segmentation fault
hobit:/tmp # halt
Segmentation fault
hobit:/tmp #

I'm not sure if it is kernel problem... but it is sure pretty
common. I wonder how much damage it will do to my filesystems: touch
foo seems to store the right year into reiserfs. I wonder if it is
still there after reboot? No, it is not. That looks like kernel bug :-).

Anyway I believe we are going to have some fun in year 2038. Even if
all systems are 64-bit by then, there will still be some 32-bit fields
hidden somewhere.

Pavel