On Sat, Oct 08, 2005 at 06:54:22AM +1000, Peter Jeremy wrote:
On Fri, 2005-Oct-07 20:17:43 +0200, Andreas Kohn wrote:
As SUSv2 wants tv_sec to be time_t[1], would it be possible to change
this to time_t on all but alpha? I guess alpha will not receive a switch
to long anymore[2].
tv_sec
Hi,
On Sat, 2005-10-08 at 06:54 +1000, Peter Jeremy wrote:
On Fri, 2005-Oct-07 20:17:43 +0200, Andreas Kohn wrote:
As SUSv2 wants tv_sec to be time_t[1], would it be possible to change
this to time_t on all but alpha? I guess alpha will not receive a switch
to long anymore[2].
tv_sec and
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
Hi,
On Fri, 2005-10-07 at 09:28 -0700, Brooks Davis wrote:
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
On Fri, 2005-Oct-07 20:17:43 +0200, Andreas Kohn wrote:
As SUSv2 wants tv_sec to be time_t[1], would it be possible to change
this to time_t on all but alpha? I guess alpha will not receive a switch
to long anymore[2].
tv_sec and time_t are int on Alpha for compatability with Tru64. Since
the
Hi,
is there any special reason for timeval.tv_sec being long?
--- sys/_timeval.h
/*
* Structure returned by gettimeofday(2) system call, and used in other
calls.
*/
struct timeval {
longtv_sec; /* seconds (XXX should be
time_t) */
suseconds_t tv_usec;
6 matches
Mail list logo