| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Long-term security
Long-term security
Posted Sep 13, 2006 11:59 UTC (Wed) by dark (subscriber, #8483)Parent article: What you should (and shouldn't) expect from 64-bit Linux (Linux.com)
64-bit systems will continue to work in 2038. It's best to be prepared.
(Log in to post comments)
Long-term security
Posted Sep 13, 2006 12:29 UTC (Wed) by clugstj (subscriber, #4020) [Link]
Well, so will 32-bit systems. We just have to "typedef long long time_t" and recompile. And of course, fix all the bugs this exposes. But, this is less work than has been and is being done to fix all the bugs in porting all applications to 64-bit.
Long-term security
Posted Sep 13, 2006 12:57 UTC (Wed) by rvfh (subscriber, #31018) [Link]
Just use an unsigned int and you'll get 68 years extra. How could time possibly be negative?
Long-term security
Posted Sep 13, 2006 13:22 UTC (Wed) by pbardet (subscriber, #22762) [Link]
To store dates before 1970 on very old apps ?
Time representation
Posted Sep 13, 2006 13:33 UTC (Wed) by rvfh (subscriber, #31018) [Link]
That particular counter is operating system time. Applications can do what they see fit, but the system time is meant to be UTC. So negative time only helps for people who use time machines ;-)
Time representation
Posted Sep 13, 2006 13:42 UTC (Wed) by HenrikH (guest, #31152) [Link]
Exactly what has UTC with this issue? Negative values for time_t is perfectly legal and is meant to reference dates and times before 1970
Time representation
Posted Sep 13, 2006 14:10 UTC (Wed) by rvfh (subscriber, #31018) [Link]
The original post about 2038 is about OS time, the epoch counter in UNIX operating systems. This time is meant to represent the time now for OS use (file modified time and so on).
Applications might need to deal with 6000 B.C., but they do not need to set the OS time to that date, so it's their problem to handle the time as they see fit, and use a 1024-bit counter for that.
I hope I am not misunderstanding your point, otherwise feel free to correct me!
Time representation
Posted Sep 13, 2006 15:56 UTC (Wed) by HenrikH (guest, #31152) [Link]
Both yes and no, the original post talks about time_t beeing 32-bits since it is defined as an int. time_t is used both by the kernel to track the current time and by libc to represent time for userspace applications. There is no separation between the two. time_t is used extensibly by userspace programs to store dates and times which of course can be hsitorical times aswell, and the time and date functions in libc uses time_t for this purposes aswell.
Time representation
Posted Sep 13, 2006 16:08 UTC (Wed) by rvfh (subscriber, #31018) [Link]
In this case one can only code dates which are 68-odd years either side of 1 January 1970, i.e. 1902 to 2038. This does not even cover birth dates for many countries' population!
No, really, applications need a lot more possibilities than the operating system does, so back to square one: the OS could have an unsigned number for its current epoch.
Quoting David Schwartz
on the same kind of discussion:
Application programmers can allocate space or not, that's their
decision. Well-written application code either uses its own date classes
or uses date classes that are known to be safe for the range of dates the
application is intended to handle. If we're talking about fixing
application code, why are we doing it on the linux-kernel list?
Why is time_t not unsigned
Posted Sep 13, 2006 16:29 UTC (Wed) by rvfh (subscriber, #31018) [Link]
I found an answer to my own question, in case anybody is interested...
If you start a system with time = 0 and local time is GMT-something (any place west of Greenwich: Brasilia (GMT-3), New York (Eastern time), ...), then you get time before 1 January 1970. Well, you don't if time_t is unsigned! You get time in 2107 instead :-(
Time representation
Posted Sep 13, 2006 19:35 UTC (Wed) by HenrikH (guest, #31152) [Link]
Who ever said that it was wise by the applications to use time_t ;-)
Anyways one reason that it is used is that time_t has excellent support in libc with conversion functions between localtime and UTC for current and historical dates. So one does not have to find another date library. Also since you get a time_t from the gettimeofday() systemcall one tend to use the very same variable in the application, it is not the the kernel is completely isolated into its own world.
Time representation
Posted Sep 13, 2006 20:39 UTC (Wed) by dark (subscriber, #8483) [Link]
the OS could have an unsigned number for its current epoch.Not anymore, it can't :) Too many applications rely on it being signed. (And if you don't mind breaking those, then why not move to 64 bits instead?)
One reason they rely on it is that in addition to using time_t to represent dates, they subtract time_t values from each other to represent intervals.
For example:
while (deadline - time() > 15) { ... do something that might take 15 seconds ... }
If time_t is unsigned, this condition will be true if time() is already past the deadline, thus causing an infinite loop. Well, not really infinite... just 68 years :)
Long-term security
Posted Sep 13, 2006 13:58 UTC (Wed) by smitty_one_each (subscriber, #28989) [Link]
Well, it was my first DB app, and I didn't bother sorting the timestamps.Q: No one would override the warnings and violate the start/stop sequence of the data entries, would they?
A: Just the first user.
Long-term security
Posted Sep 13, 2006 14:19 UTC (Wed) by nix (subscriber, #2304) [Link]
They'll only continue to work if we've fixed all the places where 32-bit time_t is wired into data on disk, filesystems layouts, and so on. (Mind you those'll have to be fixed sooner or later anyway).