2038: only 21 years away

2038: only 21 years away

Posted Mar 17, 2017 1:35 UTC (Fri) by gdt (subscriber, #6284)
In reply to: 2038: only 21 years away by dd9jn
Parent article: 2038: only 21 years away

undefined whether it is signed or unsigned

C is even more undefined than you suggest. An implementation must use an "arithmetic type", but need not supply an arithmetic value within that type. The ANSI C Rationale says

No arithmetic properties of these types are defined by the Standard … The representation need not be a count of some basic unit; an implementation might conceivably represent different components of a temporal value as subfields of an integer type.

So you can see that ANSI C gives a programmer wanting to write portable time_t handling code very little. Only the ability to compare a time against (time_t)(-1) to check for errors. You could argue that ANSI C allows a time_t to be compared for equality, but you friend could counter-argue that the Standard doesn't forbid multiple representations for the same time in a time_t. ANSI C does require that a time in a struct tm returned by a library has only one representation. The ANSI C committee created difftime() to give the language more time_t handling ability; however that returns a double, which is problematic for some programming tasks.

Thankfully POSIX/SUS applies additional requirements for time_t on UNIX-like systems. "The time() function shall return the value of time in seconds since the Epoch".

As far as I can tell, POSIX/SUS makes no statement on the signedness or unsignedness of time_t, thus neither can be relied upon by a programmer.

Implementation practice in AT&T and BSD UNIXen prior to POSIX was that time() was signed. Of course, such practice shouldn't be relied upon by a programmer.

---

to post comments