Messages in this thread | | | Subject | Re: time_t size: The year 2038 bug? | Date | Tue, 11 Jan 2000 20:23:28 -0300 | From | Horst von Brand <> |
| |
Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> 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 whatsoever. -- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl 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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |