* year 9223372034708485227 problem
@ 2004-09-22 21:30 Pavel Machek
2004-09-22 21:45 ` year 2038 problem on x86-64 Pavel Machek
0 siblings, 1 reply; 2+ messages in thread
From: Pavel Machek @ 2004-09-22 21:30 UTC (permalink / raw)
To: kernel list
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
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: year 2038 problem on x86-64
2004-09-22 21:30 year 9223372034708485227 problem Pavel Machek
@ 2004-09-22 21:45 ` Pavel Machek
0 siblings, 0 replies; 2+ messages in thread
From: Pavel Machek @ 2004-09-22 21:45 UTC (permalink / raw)
To: kernel list
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 ;-).
And we have some nearer problems, too.
#ifdef __ARCH_WANT_SYS_TIME
/*
* sys_time() can be implemented in user-level using
* sys_gettimeofday(). Is this for backwards compatibility? If so,
* why not move it into the appropriate arch directory (for those
* architectures that need it).
*
* XXX This function is NOT 64-bit clean!
*/
asmlinkage long sys_time(int __user * tloc)
{
int i;
struct timeval tv;
do_gettimeofday(&tv);
i = tv.tv_sec;
if (tloc) {
if (put_user(i,tloc))
i = -EFAULT;
}
return i;
}
... __ARCH_WANT_SYS_TIME actually is set on x86-64.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-09-22 21:48 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-22 21:30 year 9223372034708485227 problem Pavel Machek
2004-09-22 21:45 ` year 2038 problem on x86-64 Pavel Machek
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.