jdc@coris.demon.co.uk ("Julian Coleman") writes:
> Grabbed the time using rdate from an Ultrasparc1 yesterday.  Hmm, February 7
> 2036.  Looking at usr.sbin/inetd/inetd.c, machtime(), machtime_stream() and
> machtime_dg() use a long to store the time value and send this straight out
> on the wire.  On the Ultrasparc, this is 8 bytes.  The other machine was
> only expecting 4.
> 
> So, should the machtime..() calls use time_t (and be consistent with rdate.c)
> and cast the return from gettimeofday(), or should gettimeofday() return 
> something else (int, time_t, u_int32_t)?  Should time_t be a u_int32_t?

time_t isn't guaranteed to be any particular fixed size, and
gettimeofday() and other similar calls and contents of structures used
by them are standardized so you can't change them.

the hints you want should be taken from the comments in inetd.c:

        /* Return 32 bit time since 1970 */
        { "time",       SOCK_STREAM,    0, 0,   machtime_stream },
        { "time",       SOCK_DGRAM,     0, 0,   machtime_dg },

and:

 * Return a machine readable date and time, in the form of the
 * number of seconds since midnight, Jan 1, 1900.  Since gettimeofday
 * returns the number of seconds since midnight, Jan 1, 1970,
 * we must add 2208988800 seconds to this figure to make up for
 * some seventy years Bell Labs was asleep.

(which end up being inconsistent; the time is really since 1900.)

and the comments in rdate:

 *      Uses the rfc868 time protocol at socket 37.
 *      Time is returned as the number of seconds since
 *      midnight January 1st 1900.



You might also look in the RFC.  8-)


Anyway, from my reading, both inetd and rdate should be using
uint32_t.



cgd