On Thu, Jun 17, 2004 at 01:57:36PM -0400, "Olson, Arthur David (NIH/NCI)" <olsona@dc37a.nci.nih.gov> wrote:
Given that time_t has been a 32-bit entity since day one of UNIX, there are
It's not on a lot of existing UNIX systems, where it already is 64 bit.
a slew of binary executables out there that are built on the premise, as
Binary executables are not a problem, as ABI changes are rare. It's no problem to support both 32 and 64 bit time() calls on the same system, even within the same executable. This is already standard practise.
well as plenty of values stored in disk files (take UNIX accounting logs, please).
The example is mostly a non-issue, as it ahs been dealt with in existing implementations (quote databases are another - bad - example). Databases are a bigger concern, but there are very few (if any) database systems that directly store time_t as it is. One of the reasons is that portable rpogramming always required to allow for different time_t representations.
That makes it an extremely bad idea to redefine time_t as a 64-bit
I very much disagree here with you. It might be helpful to some people to keep it a 32 bit value, but the problem needs to be dealt with before 2038, wether time_t is 32 bit or not, because at that point it will wrap, so any databses still based on 32 bit time_t's WILL have to be reworked. In essence, I think your proposal to force it to 32 bit is very harmful as it encourages problems similar to Y2K. Most existing programs don't need changes to work with a 64 bit time_t now, they just need to be recompiled. Forcing extra (and non-standard) calls means every program must be changed.
with differently named functions to manipulate them). The historic precedent in the UNIX realm is the addition of the "lseek" system call once files got larger than good old "seek" could handle
The reaosn was that the units was changed, so the filesystem call was incomaptible. Even early unix had no problem with having two seek calls, one for 16 bit and one for 32 bit. So they could have kept the name. The name was changed because the sematic had changed. To the contrary, the 32->64 bit transition many years ago involved no such adition of extra syscalls or functions - all you need is to recompile your program under the new environment and it can do 63 bit I/O, except when it has bugs (which would in turn result in a 32 or 31-bit-capable program only, which wouldn't be worse).
Bottom line: we should probably not be doing a lot of work to support 64-bit time_t implementations since we don't want to encourage such implementations.
I think this is a very bad decision. It's exactly the same bad decision as the decison that "two digits are enough to represent a year, so don't encourage the support of 4 or more digit year values in this datatype". -- The choice of a | -----==- _GNU_ | ----==-- _ generation Marc Lehmann +-- ---==---(_)__ __ ____ __ pcg@goof.com |e| --==---/ / _ \/ // /\ \/ / http://schmorp.de/ --+ -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE | |