Linux-kernel mailing list archive 1999-22,: Re: Migrating to larger numbers

# Re: Migrating to larger numbers

Ard van Breemen (ard@cstmel.nl.eu.org)
Tue, 1 Jun 1999 07:39:40 +0200 (CEST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Dan Koren: "Re: Buffer Cache API"
- Previous message: Richard Gooch: "Re: How can Emacs get a unique ID per Linux reboot?"

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/

- Next message: Dan Koren: "Re: Buffer Cache API"
- Previous message: Richard Gooch: "Re: How can Emacs get a unique ID per Linux reboot?"