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?