Re: Y2K+38 disaster in debian?

[Michael Stone <mstone@itri.loyola.edu>]

Quoting Philip Thiem (ptt@umr.edu):
> Why would 32-bit apps be limited to 32 bit integers??  Didn't we have 32
> bit avallible to us on the 286??  If not, I'm certain we were able to
> get around it then.  Also if any one wants to make use of MMX registers
> there is even a 64-bit ASM MOV command avalible. 
> 
> In fact on my (nonmmx)k6-processor(I don't have a chance to test on a
> 386) this program returns 8 bytes(64 bits) just as it should;
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main(void)
> {
>   long long test;
>   printf("\n\n%i bytes\n\n", sizeof(test);
>   return 0;
> }

1) Posix requires time_t to be a standard integer type. "long long" is
(was?) a non-standard extension. (It was being discussed as a possible
standard.)

2) 64 bit math is _very_ slow on a 32 bit machine. Since time_t is used
all over the place (e.g., the filesystem) you'd seriously slow things
down by making it 64 bits. 

3) Since 64 bit archs already use a 64 bit time_t, this is a problem
that will go away when 32 bit machines are phased out (I can't see most
hardware lasting forty years.)

4) Any program that stores data to disk as a time_t is already broken:
portability is not assured. Any disk file should be stored in a
platform-independent fashion.

Mike Stone