Ansgar <ans...@43-1.org> 于2020年2月13日周四 下午5:29写道: > > Steve McIntyre writes: > > wzss...@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