Messages in this thread | | | From | Willy Tarreau <> | Subject | Re: time_t size: The year 2038 bug? | Date | Thu, 6 Jan 100 01:35:38 +0100 (CET) |
| |
Hi past-Y2k and pre-Y2038K folks !
Well, I think there are ways to progressively help developpers to switch to Y2038. The main principle would be :
- let the kernel compute on 32 bits for now. Better for performance. - glibc should return 64 bits results for each function return so that if the result is interpreted as 64 bits, it's good, and if interpreted as 32 bits, it's still good till 2038-epsilon. - glibc should accept as input 32 bits values for the moment so that inputs from 64 bits are truncated to 32 bits to keep compatible with other 32 bits apps. - when glibc fills a structure, it should only write the 32 bits (act as it's currently the case), but it would be to the 64-compliant apps to initialize these structs to 0 before the first call to the system calls.
-> 32-bits code should still work -> it would be possible to begin to develop 64 bits code, even if it is used only as 32 bits for the moment. When we are ready to eliminate all the old 32 bits apps, then glibc could accept to work on true 64 bits data, keeping the same interface and the kernel would use its new 64 bits counter, transparently for glibc and apps.
it's obvious that this last step will break 32-bits software, at least for structure-filling, but since this software will not be Y2038-compliant anymore, what's the matter ?
Of course it's easy to say, but to do ...
Just my 2 cents.
Willy
-- Willy Tarreau - mailto:willy@meta-x.org - http://www-miaif.lip6.fr/willy/ System and Network Engineer at NOVECOM ( France ) - http://www.novecom.fr/ Magistere d'Informatique Appliquee de l'Ile de France ( MIAIF ), Year 1997
- 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/
| |