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.unix-wizards
Subject: Re: 4.2BSD ctime() arguments
Message-ID: <3741@utzoo.UUCP>
Date: Thu, 12-Apr-84 17:06:22 EST
Article-I.D.: utzoo.3741
Posted: Thu Apr 12 17:06:22 1984
Date-Received: Thu, 12-Apr-84 17:06:22 EST
References: <398@noscvax.UUCP>
Organization: U of Toronto Zoology
Lines: 50

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