struct timeval: why is tv_sec long?

[Brooks Davis]

On Fri, Oct 07, 2005 at 02:22:22AM +0200, Andreas Kohn wrote:
> Hi,
> 
> is there any special reason for timeval.tv_sec being long?

tv_sec is presumably long becuase that way 64-bit platforms end up with
timevals that don't suffer from the 2038 bug.  time_t is also long (or
rather synonimous with it) on all but alpha platforms.

> --- sys/_timeval.h
> /*
>  * Structure returned by gettimeofday(2) system call, and used in other
> calls.
>  */
> struct timeval {
>         long            tv_sec;         /* seconds (XXX should be
> time_t) */
>         suseconds_t     tv_usec;        /* and microseconds */
> };
> ---
> 
> I just stumbled across this code in an application,
> ---
> timeval tv;
> gettimeofday(&tv, 0);
> 
> char tbuf[64];
> struct tm tmp;
> strftime(tbuf, sizeof(tbuf), "%b %d %H:%M:%S", localtime_r(&tv.tv_sec,
> &tmp));
> ---
> 
> and this fails to compile on FreeBSD. I fixed the application code now,
> but I do wonder why that XXX in sys/_timeval.h is there.
> _timeval.h came into existence on 31-Dec-2002, before that timeval was
> defined in sys/time.h with both tv_sec and tv_usec as long.
> 
> Could anyone offer any pointers?

You probably can just cast the tv.tv_sec to a time_t.  Alternativly, you
could allocate a time_t and assing tv_sec to it since that will work on
alpha where the other won't.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20051007/fca7a5ca/attachment.bin