![]() | |||||||||||||
Messages in this thread |
> 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. It will not break them, it will simply fail to fix them. If enlarging a 'time_t' breaks a program, the program was broken to begin with. > 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. Umm, no they don't. If _you_ decide to write a value to a file or pass it over a network connection, or pass it between a program and a dynamically linked library, _you_ have to choose the size of the object and its bit representation. It is programming negligence to fail to do this. If you have done this, changing a 'time_t' won't hurt you. If you haven't done this, nothing will save you. > > 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. Right! That _application_ code needs to be fixed now. Before we even thing about fixing the system and libraries. > 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. That punishes the correctly written applications. > 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. That's a good compromise. But I still maintain that code that relies on any specific bit representation or size for opaque types is broken and should be fixed. DS - 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/ | ||||||||||||
| Last update: 2005-03-22 12:55 [from the cache] ©2003-2008 | |||||||||||||