On Thu, Feb 13, 2020 at 04:08:22PM +0100, Andrej Shadura wrote:
On Thu, 13 Feb 2020, 10:40 YunQiang Su, <wzssyqa@gmail.com> wrote:
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?
Aren't such things already broken on amd64?
If they're trying to talk, then yes. On-disk structures are probably much more common than network protocols and not necessarily already addressed. Even stuff like last(1) or who(1) would need changes if you redefine the size of a time_t. And these aren't simple changes--files which weren't intended to be portable don't generally store anything about how big their time_t is, so you need heuristics to figure that out and then make some tough decisions about how to proceed. (E.g., in the case of wtmp you'd probably not want to just start writing larger records halfway through a file, but you also have a very large number of programs that can potentially write those records and upgrading them simultaneously is impossible. A file with mixed record sizes is probably not 100% recoverable.)