Re: Y2K-like bug to hit Linux computers! - Info of the day

[jnf <jnf@innocence-lost.us>]

firstly lemme say im hardly any authority, so feel free to disregard
anything I have to say, lord knows everyone else does.

I would say that this is more or less a known issue, and not really an
issue- at least not as far as I can see- I would hope that by 2038 64b (or
larger) int's would be standard.

> but shall i ask how
> counting something that increase can give a negative number?

what would you expect MAX_INT+1 to yield?
as a short example:

submission$ cat test.c
int main(void) {
        signed short int count = 0;

        while(count >= 0 ) {
                printf("count: %d\n", count++ );
        }
        printf("count: %d\n");
}
submission$ gcc -o test test.c
submission$ ./test
[...]
count: 32767
count: -1


> second... is the counter on the software? until now i thought that the counter
> is a clock on the hardware...

IIRC the software keeps track of the count, so even though its physically
a hardware clock, the software still has to count it- if a 32b int can
only represent 2^32-1, then we will hit a wall, for our purposes this will
be in 2038, unless by then linux switches to a 64b counter, which is quite
probably (and possibly already done under amd64 and the likes?)

> so how is this related with Linux? then the
> counter overflow... this will be a hardware issue... not a software issue (
> the software will have to support the bigger hardware counter but to do that
> the bigger hardware has to exist first...)

I could be wrong here, but I don't think the hardware even keeps track of
the clock ticks, rather it just ticks and lets the software keep track.

> BTW is there anyone that plan to use his embedded devise until 2038????

not exactly an embedded device however I have my feet resting on an ibm
ps/2 286 running minix. Some people hold onto things longer than other
people.