On Sun, Jan 09, 2000 at 10:47:29AM -0800, David Schwartz wrote:
....
> > > 5) Enlarge 'time_t' for newly-compiled code. Try
> > > recompiling old code. See
> > > what breaks and fix it. (Beginning around 2025.)
>
> > This should be step 1.
>
> It can't be. As soon as we enlarge 'time_t', non-compliant code will
> break. There's too much non-compliant code out there. I don't want to wait
> until all the non-compliant code is fixed to begin working on the problem.
> And I don't want to needlessly break code today that would work fine for 30+
> years.
I don't know what IA64 time_t will be, however if DEC Alpha is
of any model, the problem is *not* that bad. (Alpha has 64-bit
time_t)
Presuming the software in next 20 years will widely be written
in 64-bit machines (with 64-bit time_t), it will become trivial
to change time_t in 32-bit cadgets.
After all Linux 'jiffies' counter does overflow far sooner, and
system seems to survive it just fine these days. (ia32)
> DS
/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:14 EST