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/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:15 EST