3 ms·
The tradeoff there is that you would be unable to use time_t to express times before 1 Jan 1970 (iinm). That may or may not be important depending on use case.
by seanhunter 5y ago
The tradeoff there is that you would be unable to use time_t to express times before 1 Jan 1970 (iinm). That may or may not be important depending on use case.
- mlyle 5y agoAnother tradeoff is that you can't just subtract two time_t's and get a negative value for an interval. I'd wager this is a far more common problem. E.g. you can't do... time_t completion = time(NULL) + 30; do { time_t remaining = completion - time(NULL); /* ... */ } while (remaining > 0); Without risking a sporadic infinite loop.
- strenholme 5y agoWe can convert that unsigned 32-bit number in to a 64-bit number: #include <stdint.h> int64_t completion = (int64_t)time(NULL) + 30; do { int64_t remaining = completion - (int64_t)time(NULL); /* ... */ } while (remaining > 0); There’s some slowdown doing 64-bit int math on a 32-bit system, but the above works.
- mlyle 5y agoYes. We're talking about growing time_t from int32_t to int64_t, instead of uint32_t. If you change it to uint32_t behind the scenes, some code will silently fail while compiling OK, because it was not expecting unsigned math.