Re: Win64 support, second take

["Romanchuk, Mike" <mromanchuk at empirix dot com>]

> "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.