4 ms·

There's no fundamental reason that time_t needs to be 32-bit on 32-bit systems, it's just that a ton of software casts/coerces time_t to/from int.

ComputerGuru 6y ago
GP's point still stands. MS-DOS fits that range without 64-bits, a separately correct design decision would have been to use 64-bits of time from the start. Poor software casts/stores time_t in int because that was good enough for decades - if it didn't fit an int from the start, they wouldn't be doing that (or if an int were enough by having different semantics, it would also be OK for them to keep doing that).
- kps 6y ago
  > a separately correct design decision would have been to use 64-bits of time from the starta separately correct design decision would have been to use 64-bits of time from the start On a 16-bit machine when memory cost close to a dollar a byte?
  - rat87 6y ago
    yes what percent of memory do dates usually use? Even in a spreadheet, it wouldn't double needed memory at worst it would probably be signficantly less then 10% extra memory
    - eropple 6y ago
      A PDP-11/20 could address (without extensions) 32 16-byte kilowords, or 64 kilobytes, of RAM. Most machines shipped with twelve kilowords, or 24 kilobytes, of RAM. Tell me again how free the creators of Unix should've been with it.
- wtallis 6y ago
  > GP's point still stands. MS-DOS fits that range without 64-bits 32-bit Unix timestamps would have a broader range than MS-DOS timestamps if they made the same sacrifice in resolution and only had 2-second precision rather than single-second precision [1]. And if Unix timestamps additionally used 32-bit unsigned numbers to sacrifice the ability to represent timestamps before the beginning of the epoch, then the year 2038 problem would instead be more of a year 2242 problem. [1] https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-dosdatetimetofiletime https://docs.microsoft.com/en-us/windows/win32/api/winbase/n...
  - bregma 6y ago
    I work with a fully POSIX-compliant OS that uses 32-bit unsigned int time_t. Unfortunately, most software these days (including the runtimes of major production languages) assume incorrectly that time_t is an unsigned int because that's what it is in the GNU C library used on GNU/Linux, and they end up using it as a general arithmetic type. The end result is undefined behaviour. But hey, it just happens to work on Linux so it must be correct. Grrr.
    - murderfs 6y ago
      Why would it result in undefined behavior? Overflow behavior is only defined on unsigned types. Also, why should people care about your special snowflake OS? The C standard doesn't even specify that time_t has to be an integral type, but anyone who expects code to cope with a floating point time_t is deluded. Why is your case any different?
      - bregma 6y ago
        My special snowflake OS is embedded in millions of devices all over the world in safety-critical applications. It's not broken, it's the third-party software that incorrectly assumes time_t is a general integer arithmetic type that's broken. The ISO C11 standard only says that time_t is a real type that holds values >= 0. The minute you start performing arithmetic on that type and checking if the result is less than zero you're entering undefined behaviour territory. For example, does the following program halt? int main() { for (unsigned i = 1; i >= 0); --i) ; } The answer is "maybe". The C standard defines an infinite loop like this as undefined behaviour ISO 9899:2011 [6.8.5/6].
    - SomeoneFromCA 6y ago
      Linux and BSDs. They are still used quite often, and for the most cases are compatible with Linux.

ComputerGuru 6y ago

GP's point still stands. MS-DOS fits that range without 64-bits, a separately correct design decision would have been to use 64-bits of time from the start. Poor software casts/stores time_t in int because that was good enough for decades - if it didn't fit an int from the start, they wouldn't be doing that (or if an int were enough by having different semantics, it would also be OK for them to keep doing that).

kps 6y ago
> a separately correct design decision would have been to use 64-bits of time from the starta separately correct design decision would have been to use 64-bits of time from the start On a 16-bit machine when memory cost close to a dollar a byte?
- rat87 6y ago
  yes what percent of memory do dates usually use? Even in a spreadheet, it wouldn't double needed memory at worst it would probably be signficantly less then 10% extra memory
  - eropple 6y ago
    A PDP-11/20 could address (without extensions) 32 16-byte kilowords, or 64 kilobytes, of RAM. Most machines shipped with twelve kilowords, or 24 kilobytes, of RAM. Tell me again how free the creators of Unix should've been with it.
wtallis 6y ago
> GP's point still stands. MS-DOS fits that range without 64-bits 32-bit Unix timestamps would have a broader range than MS-DOS timestamps if they made the same sacrifice in resolution and only had 2-second precision rather than single-second precision [1]. And if Unix timestamps additionally used 32-bit unsigned numbers to sacrifice the ability to represent timestamps before the beginning of the epoch, then the year 2038 problem would instead be more of a year 2242 problem. [1] https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-dosdatetimetofiletime https://docs.microsoft.com/en-us/windows/win32/api/winbase/n...
- bregma 6y ago
  I work with a fully POSIX-compliant OS that uses 32-bit unsigned int time_t. Unfortunately, most software these days (including the runtimes of major production languages) assume incorrectly that time_t is an unsigned int because that's what it is in the GNU C library used on GNU/Linux, and they end up using it as a general arithmetic type. The end result is undefined behaviour. But hey, it just happens to work on Linux so it must be correct. Grrr.
  - murderfs 6y ago
    Why would it result in undefined behavior? Overflow behavior is only defined on unsigned types. Also, why should people care about your special snowflake OS? The C standard doesn't even specify that time_t has to be an integral type, but anyone who expects code to cope with a floating point time_t is deluded. Why is your case any different?
    - bregma 6y ago
      My special snowflake OS is embedded in millions of devices all over the world in safety-critical applications. It's not broken, it's the third-party software that incorrectly assumes time_t is a general integer arithmetic type that's broken. The ISO C11 standard only says that time_t is a real type that holds values >= 0. The minute you start performing arithmetic on that type and checking if the result is less than zero you're entering undefined behaviour territory. For example, does the following program halt? int main() { for (unsigned i = 1; i >= 0); --i) ; } The answer is "maybe". The C standard defines an infinite loop like this as undefined behaviour ISO 9899:2011 [6.8.5/6].
  - SomeoneFromCA 6y ago
    Linux and BSDs. They are still used quite often, and for the most cases are compatible with Linux.