This was my workaround for 1.6.x, more eyeballs and feedback welcome.
On Thu, Aug 30, 2018 at 12:23 AM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:
>
> Nick, please note your error in line 58 here is still not cured;
>
>
http://svn.apache.org/viewvc/apr/apr/branches/1.6.x/time/win32/time.c?view=annotate
>
> This was buried in pull req 13, where it became a fatal bug to that
compiler.
>
> On Wed, Aug 29, 2018, 05:06 Nick Kew <n...@apache.org> wrote:
>>
>>
>> > On 27 Aug 2018, at 04:18, William A Rowe Jr <wr...@rowe-clan.net>
wrote:
>> >
>> > Let's take a few more days on this. We are getting more and more good
suggestions as git merge requests to girhub.com/apache/app that are worth a
look.
>>
>> What do you envisage doing with those days?
>>
>> The motivation for a release is to fix one problem, and without risk of
>> introducing any new problem:
>>
>> > There are a lot of reports of PR62644 from solaris users of httpd, can
>> > anyone RM?
>>
>> Reviewing activity since 1.6.last, I see nothing else whose risk/reward
profile
>> cries out for a backport, unless it be some of the Windows stuff I'm in
no
>> position to judge. Are you right now reviewing that?
>>
>> I also looked at your github link. Among those I checked out I don't
see anything
>> there that should be dealt with in a hurry (i.e. now) rather than at
leisure in the
>> context of a minor-bugfix-release.
>>
>> --
>> Nick Kew
Index: time/win32/time.c
===================================================================
--- time/win32/time.c (revision 1814503)
+++ time/win32/time.c (working copy)
@@ -54,9 +54,6 @@
static const int dayoffset[12] =
{0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334};
- if (tm->wMonth < 1 || tm->wMonth > 12)
- return APR_EBADDATE;
-
/* Note; the caller is responsible for filling in detailed tm_usec,
* tm_gmtoff and tm_isdst data when applicable.
*/
@@ -111,6 +108,7 @@
FileTimeToSystemTime(&ft, &st);
/* The Platform SDK documents that SYSTEMTIME/FILETIME are
* generally UTC, so no timezone info needed
+ * The time value makes a roundtrip, st cannot be invalid below.
*/
SystemTimeToAprExpTime(result, &st);
result->tm_usec = (apr_int32_t) (input % APR_USEC_PER_SEC);
@@ -127,6 +125,7 @@
FileTimeToSystemTime(&ft, &st);
/* The Platform SDK documents that SYSTEMTIME/FILETIME are
* generally UTC, so we will simply note the offs used.
+ * The time value makes a roundtrip, st cannot be invalid below.
*/
SystemTimeToAprExpTime(result, &st);
result->tm_usec = (apr_int32_t) (input % APR_USEC_PER_SEC);
@@ -158,6 +157,7 @@
* because FileTimeToLocalFileFime is documented that the
* resulting time local file time would have DST relative
* to the *present* date, not the date converted.
+ * The time value makes a roundtrip, localst cannot be invalid below.
*/
SystemTimeToTzSpecificLocalTime(tz, &st, &localst);
SystemTimeToAprExpTime(result, &localst);
@@ -187,6 +187,7 @@
TIME_ZONE_INFORMATION tz;
/* XXX: This code is simply *wrong*. The time converted will always
* map to the *now current* status of daylight savings time.
+ * The time value makes a roundtrip, st cannot be invalid below.
*/
FileTimeToLocalFileTime(&ft, &localft);
@@ -298,6 +299,9 @@
/* The Platform SDK documents that SYSTEMTIME/FILETIME are
* generally UTC, so no timezone info needed
*/
+ if (tm->wMonth < 1 || tm->wMonth > 12)
+ return APR_EBADDATE;
+
SystemTimeToAprExpTime(aprtime, *ostime);
return APR_SUCCESS;
}
