On Thu, 6 Sep 2018 at 01:00, D. Hugh Redelmeier <[email protected]> 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 > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan-dev _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
