From: "Romanchuk, Mike" <mromanchuk@empirix.com>
To: <pthreads-win32@sourceware.org>
Subject: Re: Win64 support, second take
Date: Thu, 10 May 2007 08:40:00 -0000 [thread overview]
Message-ID: <BD261180E6D35F4D9D32F3E44FD3D90107772D73@EMPBEDEX.empirix.com> (raw)
> "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.
next reply other threads:[~2007-04-26 4:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-10 8:40 Romanchuk, Mike [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-01-26 13:47 Stefan Eilemann
2007-01-27 1:45 ` Ross Johnson
2007-01-29 13:49 ` Streithorst, Kip
2007-01-29 13:54 ` Stefan Eilemann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BD261180E6D35F4D9D32F3E44FD3D90107772D73@EMPBEDEX.empirix.com \
--to=mromanchuk@empirix.com \
--cc=pthreads-win32@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).