Messages in this thread | | | From | "Khimenko Victor" <> | Date | Sun, 9 Jan 2000 23:27:59 +0300 (MSK) | Subject | RE: time_t size: The year 2038 bug Summary: |
| |
In <000c01bf5ad1$faf68d70$021d85d1@youwant.to> David Schwartz (davids@webmaster.com) wrote:
>> On Fri, 7 Jan 2000, David Schwartz wrote:
>> > 2) Add support for a flexible time API to the kernel and >> > libc. This API, >> > and code that uses it, should remain Y2.038K-compliant without >> > a recompile. >> > (Design now, start coding in 2-3 years, ideally standardize >> > within 10 years >> > and apply across most platforms within 20 years)
>> The time_t interface and associated functions _are_ that API. >> Any program that uses them properly would need to be recompiled on the >> redefinition of time_t, but that is it.
> The problem is that too much code makes assumptions about the structure of > 'time_t'. If we're going to change that structure, we're going to break > things.
Better to break things once then to build kludge over kludge.
> So we'd either have to break current code, wait until everything else is > fixed to change it, or replace it with a new API. I strongly prefer > the third option.
Of course the onlywayis to break current code :-) This way there are exist chance that code will be fixed eventually. As far as existing code works it'll NOT be fixed.
>> > 5) Enlarge 'time_t' for newly-compiled code. Try >> > recompiling old code. See >> > what breaks and fix it. (Beginning around 2025.)
>> This should be step 1.
> It can't be. As soon as we enlarge 'time_t', non-compliant code will break.
And will be fixed. It was done quite a few times. How many code was broken in time of libc5 -> glibc switch ? It's fixed now or just thrown out.
> There's too much non-compliant code out there. I don't want to wait until > all the non-compliant code is fixed to begin working on the problem.
The only way is to deliberately break all already broken code. Otherwise it'll not be fixed till 2038...
> And I don't want to needlessly break code today that would work fine for 30+ > years.
This is Microsoft thinking :-) The sooner already broken code will be broken the better (now there are great chances to find someone who knows how to fix code; 30 years later such peoples will be out of business).
P.S. IMO such change belond to something like glibc 2.3/4 anyway. When kernel will be changed is not so important: most programs will not use kernel directly anyway.
- 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/
| |