[comp.lang.c] The type of time_t

karl@haddock.ima.isc.com (Karl Heuer) (10/21/88)

In article <6964@cdis-1.uucp> tanner@cdis-1.uucp (Dr. T. Andrews) writes:
>If any of the aforementioned evil lasts until 2038, we've got fun.
>That's when our present time_t should become negative.

There's nothing to prevent time_t from being typedef'd to unsigned long int,
which would double the range.  (Also, it would not surprise me if by 2038
there were no serious machines with only 32 bits in a long int.)

Of course, if you want to implement time_t with more precision than one tick
per second, then doomsday arrives much sooner.

>A more clever interface might arrange a slightly different way to indicate an
>error:
>	int mktime(struct tm *tmptr, time_t *t)
>returns 0 if it worked (*t filled in), or -1 if it fails.

That would have worked for mktime(), which was apparently an invention of the
Committee, but the time() function also needs to be able to indicate failure
(if the system has no clock).  Unfortunately time() as commonly implemented
returns a time_t as its value in addition to (optionally) storing it via the
argument, so the obvious solution (int time(time_t *), result 0 or -1) would
break existing code.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
Followups to comp.std.c.