On Wed, 5 Jan 2000, David Schwartz wrote:
> And my answer to that is that the size of a time_t has no bearing on
> properly-written application code. 'time_t' is an opaque type, and the only
> thing that is safe and legal to do with it is to pass it to and from library
> functions that take or give a 'time_t'.
It's not that simple. Dates are stored in zillions of files and databases
in 32 bit format. Changing the size of time_t will break these programs.
Problem is the same when dates are passed between two machines or between
a program and a dynamically linked library. Both sides need to use the
same size for time_t.
> People who write bad code will write bad code no matter how large a time_t
> is or isn't, and then code will break. Even if you make a time_t 64-bits,
> the people who cast it to an 'int' or write it into a 4-byte database slot
> will still be screwed on 32-bit machines.
The problem is not writing any new programs properly. The problem is the
huge amount of existing code that has been written using wrong practices.
You cannot change the size of time_t without causing much worse problems
than the ones expected around 2038.
A better solution is introducing a new ltime_t type which is 64 or 128
bits long. There is still at least 25 years time to (re)write all
applications so that they use this new type.
Another approach is making time_t to be 32 bit unsigned int which gives
about 70 more years. This change will not break any precompiled
applications (before 2038 dates). It may cause compile problems with some
programs but are detected during the compile phase and easy to fix.
Best regards,
Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
-
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 : Fri Jan 07 2000 - 21:00:05 EST