[lkml]   [2000]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: time_t size: The year 2038 bug?
>Jesse Pollard <> 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) >:-}
>[You could use some multiprecicion library for this, if you _really_ need
> it. Something I somehow doubt, at least I'm sure you don't need it bad
> enough for all other C users to suffer it]

As a language contstruct - if you don't need it, don't use it. It does
simplify/clean up a lot of definitions that have variable bit widths
depending on archetecture. I've already fought Kerberos libraries trying
to compile it as a 64 bit library - (IP addresses suddently went to 64 bits,
other "int" structures changed to 64 bits, portability was zip.)

Most of the fields that caused problems could easily have been delt with
if a "int var : 32" could have been used to create the types in the
various data structures.

As far as the library goes ... when I need it I'll use it. The code would
be much cleaner if I didn't have to make each expression a function call.
That can turn the code into lisp...
Jesse I Pollard, II

Any opinions expressed are solely my own.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:55    [W:0.046 / U:91.356 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site