3 ms·

Lots of code would break because they assume they can do signed math with time_t, though. It's a less invasive change to make it wider: largely, it's just a re

by mlyle 5y ago

Lots of code would break because they assume they can do signed math with time_t, though. It's a less invasive change to make it wider: largely, it's just a recompile, except for code that persists a time_t directly or sends it directly over the network (and both of these should be considered harmful for other reasons). The other problem is that more unsafe code in libraries, etc, will happily cooperate with 2038-safe unsigned time_t code, but will start to do bad things shortly before 2038.

anfilt 5y ago
Honestly, for network code it makes more sense when the data is received to add the time to the current era. A 64 bit timestamp is an extra 4 bytes of overhead. However, the biggest issue with a network protocol is you just can't force everyone to update everything. Now it's some in house protocol sure you can just update everything instead making the timestamp a relative value to the current era. For code running locally 64 bits is less of issue, just mainly a problem of ABI breaks. Honestly, one thing I think people overlook is file-formats... A lot them have 32 bit time fields. Also unlike a network packet the file could actually be from a previous 32 bit era. So those timestamps are ambiguous after 2038.
masklinn 5y ago
> Lots of code would break because they assume they can do signed math with time_t, though. And lots of code would break because they want to talk about pre-1970 dates. I'm definitely guilty of it, as I routinely use the timeline of the Great Emu War (1932-10-02/1932-12-10) to test time-bound features.
alkonaut 5y ago
> it's just a recompile, except for code that persists a time_t directly or sends it directly over the network Wouldn’t it also fail for all code that a) stores the return value in a plain int and not a time_t as it would truncate (but at least this is a warning) b) has time_t inside struts and allocates their size or arrays of structs assuming time_t is 4 bytes c) has time_t inside structs and assumes the byte alignment of fields following it Etc etc..
- mlyle 5y ago
  A) will be fine until 2038. I assume we have a lot of things that mashes time into an int or long. But such code is no worse off by virtue of the C library types being fixed. B) -- manual calculation of size of structs instead of sizeof() -- yah, maybe it'll happen. I don't see much code this bad. If it's ever compiled on a different word length it's already been fixed. C) Perhaps. For the most part alignment improves when you have a wider time_t, but you could have people counting the number of 32 bit fields and then needing 16 byte alignment for SSE later. Again, for the most part this penalty has been paid by code compiling on amd64, etc.
- xigoi 5y ago
  All of these fall under “harmful for other reasons”.

by mlyle 5y ago

anfilt 5y ago

Honestly, for network code it makes more sense when the data is received to add the time to the current era. A 64 bit timestamp is an extra 4 bytes of overhead. However, the biggest issue with a network protocol is you just can't force everyone to update everything. Now it's some in house protocol sure you can just update everything instead making the timestamp a relative value to the current era. For code running locally 64 bits is less of issue, just mainly a problem of ABI breaks. Honestly, one thing I think people overlook is file-formats... A lot them have 32 bit time fields. Also unlike a network packet the file could actually be from a previous 32 bit era. So those timestamps are ambiguous after 2038.

masklinn 5y ago

> Lots of code would break because they assume they can do signed math with time_t, though. And lots of code would break because they want to talk about pre-1970 dates. I'm definitely guilty of it, as I routinely use the timeline of the Great Emu War (1932-10-02/1932-12-10) to test time-bound features.

alkonaut 5y ago

> it's just a recompile, except for code that persists a time_t directly or sends it directly over the network Wouldn’t it also fail for all code that a) stores the return value in a plain int and not a time_t as it would truncate (but at least this is a warning) b) has time_t inside struts and allocates their size or arrays of structs assuming time_t is 4 bytes c) has time_t inside structs and assumes the byte alignment of fields following it Etc etc..

mlyle 5y ago
A) will be fine until 2038. I assume we have a lot of things that mashes time into an int or long. But such code is no worse off by virtue of the C library types being fixed. B) -- manual calculation of size of structs instead of sizeof() -- yah, maybe it'll happen. I don't see much code this bad. If it's ever compiled on a different word length it's already been fixed. C) Perhaps. For the most part alignment improves when you have a wider time_t, but you could have people counting the number of 32 bit fields and then needing 16 byte alignment for SSE later. Again, for the most part this penalty has been paid by code compiling on amd64, etc.
xigoi 5y ago
All of these fall under “harmful for other reasons”.