[Swan-dev] IRC: fields of timeval

[Andrew Cagney]

On Thu, 6 Sep 2018 at 01:00, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
>
> <cagney> DHR, fyi, 6d0aea9400 isn't portable
> <cagney> the timeval fields are long long on 32-bit machines
>
> Thanks.  You are right about the tv_sec field.
>
> I happened to look at select(2) when I wrote 6d0aea9400.  It says that the
> fields are long.  Nothing about long long on 32-bit machines.
>
> It turns out that that man page is wrong.  gettimeofday(2) says
>
>            struct timeval {
>                time_t      tv_sec;     /* seconds */
>                suseconds_t tv_usec;    /* microseconds */
>            };

I looked at the man page for timeval, it looks the same.

> and in the notes:
>
>        Traditionally, the fields of struct timeval were of type long.
>
> There is no reason for tv_usec to be anything other than long, int32_t,
> unsigned long, or uint_32: it needs to represent 0 - 999999.  Is it legal
> for tv_usec to have other values?

For a small -ve delay it would be negative - hence *s*useconds_t?

>
> time_t is a very natural type for seconds.  And we're going to get into
> trouble if it stays at 32 bits.  So int64_t is a good choice.  long is
> not.
>
> time_t is signed.  If tv_sec is negative, can/should tv_usec be negative?

Interesting question.

Anyway, I replaced the code with realtime_t/deltattime_t making it
more portable.

Andrew

> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev