Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.lang.c
Subject: Re: ANSI 'C'.
Message-ID: <6167@utzoo.UUCP>
Date: Fri, 22-Nov-85 20:09:41 EST
Article-I.D.: utzoo.6167
Posted: Fri Nov 22 20:09:41 1985
Date-Received: Fri, 22-Nov-85 20:09:41 EST
References: <447@graffiti.UUCP> <538@brl-sem.ARPA> <170@watmath.UUCP>, <171@watmath.UUCP>
Organization: U of Toronto Zoology
Lines: 23

> And then they define a function gmtime(const time_t *timer) that takes
> a pointer to the arithmetic value, which it is not going to change anyway.
> Why not just take the value itself instead of the pointer?

*That* one, at least, is easy to explain:  because that is the way the
Unix function does it, for historical reasons, and nobody wants to break
all that working code.

As for why the Unix function does it that way...  gmtime() predates the
arrival of "long" in C.  Back In The Bad Old Days, with no type "long",
32-bit values had to be manipulated as small arrays of int.  There were
functions to add them, etc.  Note that one can pass the address of an
array but not the array itself.  And that's why virtually all Unix library
functions that deal with time take pointers to time_t rather than just
time_t.  (If you want a really odd example, look at the time(2) manual
page -- it has two different ways to return its value!)

Oh yes, a word to the careless (and to Laura for her book):  one should
not assume that time_t and long are the same type.  Sometimes they're not,
old (e.g. V7) or broken (e.g. 4.2BSD) manuals notwithstanding.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry