Re: Y2038 - best way forward in Debian?

[YunQiang Su <wzssyqa@gmail.com>]

Ansgar <ansgar@43-1.org> 于2020年2月13日周四 下午5:29写道：
>
> Steve McIntyre writes:
> > wzssyqa@gmail.com wrote:
> >>Is there the option C?
> >>
> >>Draft:
> >>  1. define time64_t
> >>  2. for data_struct which act as a part of ABI, define a new data_struct64
> >>  3. for function which act as part of ABI, define a new version func64.
> >>  4. patch all packages to use time64_t instead of time_t step by step.
> >>  5. set a time as deadline (2030?), and then treat all packages
> >>haven't finished
> >>      the migration as rc-buggy.
> >>
> >> Since we have enough time, we can patch all packages in that period.
> >
> > It's possible, but...
> >
> > The problem here is that we have many thousands of packages to work
> > on, glibc up through other libs to all the applications that use
> > them. It's invasive work, and likely to take a very long time. Since
> > it's work that would *not* be needed for 64-bit architectures, we're
> > also likely to see push-back from some upstreams.
> >
> > 2030 is also too late to fix the problem - people are already starting
> > to see issues in some applications. We want to make a difference soon:
> > the earlier that we have fixes available, the fewer broken systems
> > will have to be fixed / removed / replaced later.
>
> For arm* and mips*, we mostly seem to be talking about special-purpose
> systems where just switching to a new architecture/port doesn't seem to
> be that much as a problem as for i386.  I think rebuilding the world and
> breaking ABI might thus be acceptable there.
>
> i386 seems different.  I think option C above would be the only
> realistic proposal so far to fix the time_t problem for (parts of) i386,
> but if glibc upstream doesn't want to expose two interfaces then i386
> will probably just break.
>

just redefine time_t to 64bit may also cause a problem:
   a bad designed and old network protocol which aims  only target 32bit system,
   a binary data packet, may contain time_t:
        struct {
            int a;
            time_t b;
        }
just define time_t to 64 will break this protocol, although it is bad designed.

Currently, the major task of 32bit ports is to keep compatible with
old system/binary.
Should we really want to break them?

> Ansgar
>


-- 
YunQiang Su