How should I access _MAX__TIME64_T?

[Jason Doucette]

Due to a CRT bug, if you pass a value into localtime_s() greater than
_MAX__TIME64_T, the program will crash:
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=266036

So, I want to range check my data. But _MAX__TIME64_T is not #defined
via #include <ctime>. I have found it only in these files:
...\crt\ctime.h
...\crt\gmtime64.c
...\crt\loctim64.c

(Note that <ctime.h> is not the same as <ctime>.) ctime.h is not in
the default directories for #includes. Thus, they never intended for
it to be available. I could either explicitly #include it, or I could
#define it myself:
#define _MAX__TIME64_T 0x100000000000i64

What is best?

[Doug Harrison [MVP]]

Either way, you'll introduce something you'll need to maintain as you move
to a different version of the compiler, but if you #include a private
header file you weren't intended to #include, you could introduce other
problems. I'd just #define it myself and include a comment noting where I
got it from. I'd also tag it with something conspicuous like
"FIXUP_MISSING_CONSTANT", that hopefully I'd remember to check when I move
to a different compiler version.

--
Doug Harrison
Visual C++ MVP

[Jason Doucette]

Hi Doug,

> Either way, you'll introduce something you'll need to maintain as you move
> to a different version of the compiler,

True.

> but if you #include a private
> header file you weren't intended to #include, you could introduce other
> problems.

Right, because it may #include things that I don't want, and it may
contain things that were never intended for users of the CRT to see /
use. So, I was leaning towards just #defining it myself.

> I'd just #define it myself and include a comment noting where I
> got it from.

Yup, already done. I'm pretty good with comments.

> I'd also tag it with something conspicuous like
> "FIXUP_MISSING_CONSTANT", that hopefully I'd remember to check when I move
> to a different compiler version.

Right. Do you mean with a Task List 'TODO' style, so that I'll bump
into it again? Perhaps I could enclose it with #defines that check
_MSC_VER that will complain if the compiler version isn't exactly the
one I am using.

Thanks for your tips, Doug.

Jason

P.S. I noticed that the Microsoft Connect page (that I linked to
above) shows that it crashes even when it is in range, i.e. equal to
_MAX__TIME64_T. So, I did some tests, and found that as soon as the
value reaches 32535244800, a little more than 2^34, it crashes. Hmm,
this time value is exactly at January 1, 3001, so that's why. This is
the real limit. This means the _MAX__TIME64_T value, as #defined in
ctime.h is wrong! (Which I should have known, since 0x100000000000 =
17,592,186,044,416, which is 557,463 years! When added to 1970, it is
well beyond year 3000.)

[Jason Doucette]

> ... I did some tests, and found that as soon as the

> value reaches 32535244800, a little more than 2^34, it crashes.  Hmm,

> this time value is exactly at January 1, 3001, so that's why. ...

I was wrong. 32535244800 is exactly at 8:00 am, January 1, 3001.

I calculated in Excel that the supposed limit of localtime_s(),
23:59:59, Dec 31, 2999, is exactly 32503679999 seconds after 1970.
This is 1 year, 2 hours, and 1 second before the 32535244800 value
required to make it crash. (Note: since localtime_s() takes local
time zone into account, it may crash with different values depending
on your geographic location.)

I would imagine that this value, 32503679999, is the safe upper limit
to use.

Jason

[Doug Harrison [MVP]]

On Wed, 16 Apr 2008 13:31:43 -0700 (PDT), Jason Doucette
<jdou...@gmail.com> wrote:

>Do you mean with a Task List 'TODO' style, so that I'll bump
>into it again?

Yes, but I've always used FIXUP_xxx.

>Perhaps I could enclose it with #defines that check
>_MSC_VER that will complain if the compiler version isn't exactly the
>one I am using.

Good idea. That'll help you remember. :)