public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
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.

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