Path: utzoo!mnetor!uunet!husc6!necntc!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Timekeeping in ANSI C (was: C machine)
Message-ID: <2527@haddock.ISC.COM>
Date: 9 Feb 88 21:27:29 GMT
References: <461@auvax.UUCP> <28700025@ccvaxa> <7159@brl-smoke.ARPA> <1131@jenny.cl.cam.ac.uk> <7216@brl-smoke.ARPA>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 23
Summary: Why must time_t be an arithmetic type?

In article <7216@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>[Why time_t and clock_t might be floating-point types]
>I seem to recall that somebody pointed out that an integer would
>overflow in an unduly small amount of real time on a system with
>a high-resolution system clock.

Yes, that's a problem.  Given an environment with only 32 bits in a long int,
and a need for much finer resolution than one second, one can't use an
integral type for timekeeping.  This applies to both clock_t and time_t.

I don't think floating-point is the answer, though; at best it seems like a
stopgap.  A more realistic solution would be to use an aggregate type.  (Egad,
the ancient PDP-11 solution may have been on the mark after all!)  The
encoding of time_t is already unspecified; as far as I can see, the only
reason it has to be an arithmetic type is so that -1 can be used as an error
return.  The clock_t type is currently guaranteed to be a simple counter, but
it also should probably be explicitly unspecified.

So, let's allow either/both of them to be a struct if necessary, and provide a
call-by-reference function for each.  Then the function return value can be 0
for success, -1 for failure.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint