4.2BSD ctime() arguments
Henry Spencer
henry at utzoo.UUCP
Fri Apr 13 08:06:22 AEST 1984
Gary K. Sloane observes:
Whenever I use gmtime() lint complains about arguments, saying that
the 1st argument to gmtime() is used inconsistently. I mucked about
and found the following:
from 'man ctime':
struct tm *gmtime(clock);
long *clock;
from /usr/lib/lint/llib-lc:
struct tm * gmtime(c) time_t *c {returns gmtime(c)}
from /usr/include/sys/types.h:
typedef int time_t;
This seems to indicate that the argument to gmtime() should be of type
time_t (according to llib-lc) which is an int (according to sys/types.h)
rather than a long (as man ctime would lead one to believe).
Compiling my program with the argument declared as an int both worked
and stopped lint from complaining. Is the man page in error or am I
hopelessly lost? And is it safe to use an int for the argument to
gmtime()?
NO NO NO NO NO!!!! The argument to gmtime() should be of type "time_t",
and ***ONLY*** time_t. Just exactly what kind of int time_t is, is
something that is machine-dependent and system-dependent; you are not
supposed to imbed such assumptions into your programs!
The manual page is a bit out of date. The lint library is correct.
The include file is machine-dependent and 4.2BSD-dependent. (And the
turkeys at Berkeley have botched it again -- it *should* have been
"typedef long time_t"! It makes no actual difference on the VAX, but
it makes the portability situation a lot clearer. There are a *LOT*
of Unix machines where time_t is not int.)
Note that using "long" is wrong too. There are machines where time_t
is not the same as long.
It is admitted that this slightly confused situation does cause
difficulties sometimes, especially when it's time to do arithmetic or
i/o on time_t values. All you can do is try to use time_t whenever
you can, and mark deviations from this as "machine-dependent".
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
More information about the Comp.unix.wizards
mailing list