On Mon, 31 May 1999 hagopiar@vuser.vu.union.edu wrote:
> But there might be a way to compromise: Would it be possible to make
> uid_t/gid_t implementation specific? As I read it, __kernel_time_t is an
> unsigned long. If my memory serves (which is growing less and less likely
> these days), this means that it is a 64-bit value on 64-bit architectures
> and a 32-bit value on 32-bit architectures. This is the route that Sun
> took with their 64-bit architectures with time_t, based on the (IMO
> perfectly valid) assumption that in 38 years 32-bit binaries will be done
> with.
This is not a valid assumption, and there is 1 good example for that:
Y2K...
The idea that 32 bit will be obsolete is probably non-true. We are still
using 4 and 8 bit microcontrollers. By then a lot of 32 bit
microcontrollers will be common in regular appliances. Those appliances
will by then be more complex, and therefore need a base that already has
no time problems.
I can see the logica with the amount of users on a 32 bit system, but not
with the time. 38 years is not that long, and I know that there still will
be a lot of 32 bit controllers out there (and even 8 and 4 bit...)


--
 intel1: 7:29am up 26 days, 7:17, 10 users, load average: 0.00, 0.00, 0.00


-
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/