Avoid a crash in mktime() when Visual C++ 2005 is

used and the input date is in year 3001.

R=eroman
BUG=4387
Review URL: http://codereview.chromium.org/28340

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10768 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 33 insertions, 3 deletions

diff --git a/base/third_party/nspr/prtime.cc b/base/third_party/nspr/prtime.cc
index cff5048..733db58 100644
--- a/base/third_party/nspr/prtime.cc
+++ b/base/third_party/nspr/prtime.cc
@@ -41,7 +41,7 @@
  *
  *     NSPR date and time functions
  *
- * CVS revision 3.36
+ * CVS revision 3.37
  */
 
 /*
@@ -71,6 +71,7 @@
 #elif defined(OS_MACOSX)
 #include <CoreFoundation/CoreFoundation.h>
 #endif
+#include <errno.h>  /* for EINVAL */
 #include <time.h>
 
 /* Implements the Unix localtime_r() function for windows */
@@ -1092,6 +1093,12 @@ PR_ParseTimeString(
         result->tm_year = year;
   if (dotw != TT_UNKNOWN)
         result->tm_wday = (((int)dotw) - ((int)TT_SUN));
+  /*
+   * Mainly to compute wday and yday, but normalized time is also required
+   * by the check below that works around a Visual C++ 2005 mktime problem.
+   */
+  PR_NormalizeTime(result, PR_GMTParameters);
+  /* The remaining work is to set the gmt and dst offsets in tm_params. */
 
   if (zone == TT_UNKNOWN && default_to_gmt)
         {
@@ -1141,7 +1148,32 @@ PR_ParseTimeString(
                      date you are handing it is in daylight savings mode or not;
                      and if you're wrong, it will "fix" it for you. */
                   localTime.tm_isdst = -1;
+
+#if _MSC_VER >= 1400  /* 1400 = Visual C++ 2005 (8.0) */
+                  /*
+                   * mktime will return (time_t) -1 if the input is a date
+                   * after 23:59:59, December 31, 3000, US Pacific Time (not
+                   * UTC as documented): 
+                   * http://msdn.microsoft.com/en-us/library/d1y53h2a(VS.80).aspx
+                   * But if the year is 3001, mktime also invokes the invalid
+                   * parameter handler, causing the application to crash.  This
+                   * problem has been reported in
+                   * http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=266036.
+                   * We avoid this crash by not calling mktime if the date is
+                   * out of range.  To use a simple test that works in any time
+                   * zone, we consider year 3000 out of range as well.  (See
+                   * bug 480740.)
+                   */
+                  if (result->tm_year >= 3000) {
+                      /* Emulate what mktime would have done. */
+                      errno = EINVAL;
+                      secs = (time_t) -1;
+                  } else {
+                      secs = mktime(&localTime);
+                  }
+#else
                   secs = mktime(&localTime);
+#endif
                   if (secs != (time_t) -1)
                     {
                       PRTime usecs64;
@@ -1163,8 +1195,6 @@ PR_ParseTimeString(
                               + 1440 * (localTime.tm_mday - 2);
         }
 
-  /* mainly to compute wday and yday */
-  PR_NormalizeTime(result, PR_GMTParameters);
   result->tm_params.tp_gmt_offset = zone_offset * 60;
   result->tm_params.tp_dst_offset = dst_offset * 60;