|
|
Boost Testing : |
From: Martyn Lovell (martynl_at_[hidden])
Date: 2005-06-02 23:06:31
Hi everyone,
Thanks for your feedback on this issue. I wanted to clarify a couple of
things about VC8's handling of time_t. Several issues have been discussed in
this thread that are somewhat unrelated, so I wanted to be sure to explain
how they related to each other.
First, in VC8 we've widened time_t to a signed 64 bit value by default, to
avoid the well-understood 2038 problem. We provide a #define that you can
use to revert to a 32 bit time_t if you need to, but we default to 64 bit
out of the box. We also provide _time32_t and _time64_t and families of
associated functions for those who need to be specific about the size of
their time_t value, for example for reading data from older file formats. I
don't think this change is at all relevant to the problem you're seeing.
Second, we've added some new safe APIs in cases where the shape of the old
API was dangerous. For example, localtime used to return a pointer to a
static struct tm, giving rise to the potential for reentrancy or other
problems. localtime_s corrects this problem. Again, I don't think this
change is related to your problem, since the new and old API have the same
validation code.
Third, we added validation to all our APIs to help detect invalid values
being passed to them and ensure that programs were only working with data in
the ranges our code is designed to handle. It is this validation that is
likely causing the problem here, because we consider negative time_t values
to be invalid.
Though the C standard does not explicitly declare negative time_t values as
invalid (it says that time_t is implementation defined), it does use
(time_t)(-1) as an invalid value to be returned from, for example, mktime().
And as others have noted, our implementation has historically not attempted
to correctly treat all negative time_t values.
Having said that, we've had feedback from a number of customers recently on
this issue. It seems that that the _invalid_parameter calls on negative
time_t values are causing portability and compatibility problems. Even
though this validation was in place for our other alpha and beta builds, and
has found real bugs in existing code, it seems that it has also recently
caused several independent testers problems -- not just the boost community.
I'm going to chat to a couple of people tomorrow to finalise this issue, but
the likelihood is we'll reduce the validation on negative time_t in
localtime (and a couple of other places) to have a similar impact to earlier
versions of VC - negative times won't work right, but they won't cause an
_invalid_parameter call. This has the disadvantage that we'll lose the
ability to catch these kinds of bugs as easily, but should reduce the
portability impact between VC and POSIX systems.
Thanks again for your feedback. Please feel free to contact me if you find
any other issues like this. We appreciate the feedback, are listening, and
will respond.
Martyn Lovell
Development Lead
Visual C++ Libraries Team
-----Original Message-----
From: boost-testing-bounces_at_[hidden]
[mailto:boost-testing-bounces_at_[hidden]] On Behalf Of Victor A. Wagner
Jr.
Sent: Thursday, June 02, 2005 1:17 PM
To: Caleb Epstein; Running Boost regression tests; Running Boost regression
tests
Subject: Re: [Boost-testing] Regression testing (1.33)
At 09:31 2005-06-02, Caleb Epstein wrote:
>On 6/2/05, John Maddock <john_at_[hidden]> wrote:
>
> > From a practical viewpoint, I guess the question is are
> > there any platforms that accept negative times? It's not as illogical
> as it
> > might appear if they do - it's the only way to represent dates before
> 1970 I
> > believe.
>
>Yes. Linux for example is more than happy to report that the
>localtime equivalent of numeric_limits<time_t>::min() is 1901-12-13
>15:45:52 EST. Solaris reports that it is -2147483648=1901-12-13
>16:45:52 EWT (Eastern War Time?)
IMO even 1900 is a rediculously late "minimum" time. especially for
boost::date_time which shouldn't be "bound" to any particular hardware or
OS.
>I would contend that the behavior of the MSVC runtime is a bug. Worst
>case It should definitely not assert and best case it should behave
>like POSIX systems do (e.g. treat it as a date before the Epoch).
>
>--
>Caleb Epstein
>caleb dot epstein at gmail dot com
>
>_______________________________________________
>Boost-Testing mailing list
>Boost-Testing_at_[hidden]
>http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Victor A. Wagner Jr. http://rudbek.com
The five most dangerous words in the English language:
"There oughta be a law"
_______________________________________________
Boost-Testing mailing list
Boost-Testing_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing