Messages in this thread | | | Date | Wed, 12 Jan 2000 12:13:18 -0500 (EST) | From | "Mark H. Wood" <> | Subject | Re: time_t size: The year 2038 bug? |
| |
On Tue, 11 Jan 2000, Horst von Brand wrote: > Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> said: > [...] > > yes it is. but the number of bits is not. On a 32 bit system "long long" is > > 64 bits. On a 64bit system it is 128. And if you need more bits that > > that you are out of luck. "long long" is imprecise, I'd prefer a construct > > like "int var: 64". This way I know exactly how many bits are available. > > If I need 128 bits for something (or even 4096) then I can define them. Or > > is there going to be a "long long long long" for 128 bits, and "long long > > long long long long .... long" to reach 4096? > > COBOL gives you this (sort of) >:-}
I was just thinking last night that this is one advantage that Multics had, being written in PL/I:
%DCL time_t char; %time_t = 'FIXED BINARY(64)'; ... DCL foo time_t; DCL bar AUTO time_t;
(or however it is you'd do typedefs in the PL/I preprocessor -- it's been too long....)
-- Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu "Where's the kaboom? There was supposed to be an Earth-shattering kaboom!" -- Marvin Martian, 01/01/2000 00:00: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/
| |