Re: B20.1: ftime bug

[Paul Berrevoets <paul@swi.com>]

Mumit Khan wrote:

> Interestingly enough, I see a 20 second or so lag in Cygwin's time than in
> the native time. Wonder if it's just due to the time taken to process the
> data and so on.

No. I submitted this bug to cygwin:

The gettimeofday() function returns wrong struct timeval values. The
sample code
below will show that the current time returned by time() and
gettimeofday() differ
by a number of seconds (depending on which timezone you are in). In
looking at the
source code for gettimeofday(), the function should NOT adjust for the
timezone.
In winsup/times.cc::gettimeofday() change:
124: totimeval (p, &f, tz.Bias * 60, 1);
to
124: totimeval (p, &f, 0, 1);
Additionally, totimeval() does not adjust for timezone correctly even if
it were
given one. In winsup/times.cc::totimeval() change:
96: x -= (long long) sub * CLOCKS_PER_SEC;
to
96: x -= (long long) sub * (int) (1e6);

Sample Code:
#include <stdio.h>
#include <sys/time.h>
int
main()
{
    struct timeval tv;
    int rc = gettimeofday(&tv, 0);
    printf("%d %d.%06d=%d\n", time(0), tv.tv_sec, tv.tv_usec, rc);
    return 0;
}

Solaris result:
solaris> ./a.out
925251283 925251283.777141=0

Windows result:
bash-2.02$ ./a.exe
925251304 925251275.656000=0
--
Paul

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com