C Code for draft-newman-datetime-00.txt

Guy Harris guy at netapp.com
Wed Jan 15 23:40:41 UTC 1997

> Why does the C library functions always access time_t values by constant
> pointers and not by simply copying the value???

I believe this was purely historical.

Back in ancient times, the support for 32-bit integral quantities in the
PDP-11 C compiler (I *did* say "ancient times"... :-)) was either absent
or not quite ready (I vaguely remember that there might have been *some*
stuff for "long" in the V6 PDP-11 C compiler, but that it wasn't
documented and that it probably wasn't ready to use).

As such, times were stored as arrays of two "int"s; the "time()"
function took, as an argument, a pointer to the first member of such an
array, so that, for example, if you did

	int now[2];

you could do


and get "now" filled in with the current time.

Eventually, "long" became supported, and times became "long"s (or
"time_t"s, which were "long"s in PDP-11 UNIX and other UNIXes with
16-bit "int"s), but the APIs weren't fully cleaned up - "time()" was
changed to return a "time_t", and to take either a pointer to a "time_t"
or a NULL as an argument, with NULL meaning "don't fill this in", but
"localtime()" wasn't changed to take a "time_t" as an argument,
presumably for binary and/or source compatibility reasons.

> I never understood this part of the C lib API.  How is portability
> increased by not using a call-by-value here?

It increased portability to machines with C compilers with 16-bit "int"s
and without adequate support for "long". :-)

> If there is any good reason that this has been done in libc, then I'd
> of course also add it to my code. I already did it for consistency with
> the existing library functions, but I'd like to know why this is supposed
> to be the right thing to do.

I wouldn't say that, except *maybe* to make the calls look like existing
calls, it's the right thing to do.  The reasons why it was done in
"libc" are compatibility with interfaces defined before 32-bit integral
types were available, which may have been a good reason for existing
interfaces but isn't necessarily a good reason for new interfaces.

More information about the tz mailing list