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.
Re:The future of 32-bit Linux
by SomeoneFromCA on Saturday December 05, 2020 @09:09AM
(#25314649)
Linux and BSDs. They are still used quite often, and for the most cases are compatible with Linux.
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?
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)
;
}
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/n...