[lkml]   [2000]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: time_t size: The year 2038 bug?
Jesse Pollard <> said:


> >[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 has a price anyway, in terms of compiler instability, size, missed
optimizations, bugs and nonportability caused by misuse, ...

> 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.)

Then Kerberos is broken. IP addresses are 128 bits, you know ;-)
Adding "gimme exactly 36 bits worth of signed foo" won't make people write
portable programs all of a sudden. I fear exactly the opposite, in fact.
Think of somebody working on a DEC 10...

> 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.

Or even better, by using "struct sockaddr_in" et al. That way it has a
fighting chance to survive to IPv6. With "int foo:32" it has none
Dr. Horst H. von Brand
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513

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.067 / U:3.932 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site