X-Spam-Check-By: sourceware.org Message-ID: Date: Sun, 11 Feb 2007 19:50:18 -0500 From: "Lev Bishop" To: cygwin@cygwin.com Subject: Re: strange bug in gettimeofday function In-Reply-To: <20070211181603.GA4950@trixie.casa.cgf.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1562006224.20070211192014@gnu.org> <20070211181603.GA4950@trixie.casa.cgf.cx> Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com On 2/11/07, Christopher Faylor wrote: > On Sun, Feb 11, 2007 at 07:20:14PM +0300, Andrew Makhorin wrote: > >Hi, > > > >I detected a strange bug in the standard function gettimeofday. > >It *sometimes* reports the time which being expressed as the integer > >number of milliseconds is *less* than the time obtained *earlier* with > >the same function. > > > >The expression 1000000 * tv.tv_sec + tv.tv_usec is calculated in > >64-bit arithmetic, so overflow cannot happen. The negative difference > >in the time values on two successive calls is about 100 milliseconds. > > > >cygcheck.out is attached. > > In cases like this a simple test case is really required. If this is > really true then calling gettimeofday in a loop should be enough to > demonstrate the problem. I have a hunch that it will be a good idea to have a look at what the result of GetSystemTimeAdjustment() is on the machine exhibiting this behaviour, at the time it exhibits this behaviour. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/