From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5668 invoked by alias); 26 Apr 2007 04:23:44 -0000 Received: (qmail 5657 invoked by uid 22791); 26 Apr 2007 04:23:43 -0000 X-Spam-Check-By: sourceware.org Received: from empbedex1.empirix.com (HELO empbedex1.empirix.com) (12.38.203.54) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Apr 2007 05:23:39 +0100 Received: from EMPBEDEX.empirix.com ([10.16.0.92]) by empbedex1.empirix.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 00:23:37 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: Win64 support, second take Date: Thu, 10 May 2007 08:40:00 -0000 Message-ID: From: "Romanchuk, Mike" To: Mailing-List: contact pthreads-win32-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sourceware.org X-SW-Source: 2007/txt/msg00023.txt.bz2 > "2. Since you are using /WX, the tests fail as soon as Visual Studio > outputs a warning, it currently outputs two different warnings, one is > related to _ftime64 being deprecated, which I can suppress by including > /D_CRT_SECURE_NO_DEPRECATE in the CFLAGS variable. The other is more > troublesome, there are about 20-30 places in the tests where you copy a > value of the _timeb structure into the timespec structure. The problem > with that is in 64-bit mode, most of the values of the _timeb structure > are 64-bit integers (ie. __time64_t) and the timespec structure only > holds 32-bit integers (ie. long) and Visual Studio issues a warning > about truncating the numbers during the assignment. Any suggestions on > what fix should be applied here?" > > The _timeb issue has not been properly resolved, although I'm guessing > it is not a problem yet. AFAICS the structure elements still represent > the same time components with the same epoch as the 32 bit version, and > no actual truncation is taking place. I'm assuming that 2038 is still > the critical year for this. Please correct me if that understanding is > wrong. I think the way to solve this is by fixing the timespec to use a time_t for the tv_sec member. As far as I can tell, this is the correct way to specify the timespec structure. This should also solve the problem because Microsoft has already made time_t 64-bit compatible. The following is from the MSDN Library: "In Visual C++ 2005, time is a wrapper for _time64 and time_t is, by default, equivalent to __time64_t. If you need to force the compiler to interpret time_t as the old 32-bit time_t, you can define _USE_32BIT_TIME_T. This is not recommended because your application may fail after January 18, 2038; the use of this macro is not allowed on 64-bit platforms." Mike.