On Tue, Mar 23, 2004 at 08:26:37PM +, Philip Martin wrote:
> "Roy T. Fielding" <[EMAIL PROTECTED]> writes:
>
> > Another bug due to a sloppy change from time_t to apr_time_t.
> > Change days to apr_time_t and remove the above conditional
> > (the case of year < 70 is already handled a few line
"Roy T. Fielding" <[EMAIL PROTECTED]> writes:
> Another bug due to a sloppy change from time_t to apr_time_t.
> Change days to apr_time_t and remove the above conditional
> (the case of year < 70 is already handled a few lines below).
* time/unix/time.c (apr_time_exp_get): Remove year check that
"Roy T. Fielding" <[EMAIL PROTECTED]> writes:
>> Is the function supposed to validate it's input? If the user supplies
>> a large, positive or negative, value for xt->tm_year then the
>> calculation may overflow. If the user supplies an xt->tm_mon outside
>> the range 0-11 the function will read
Is the function supposed to validate it's input? If the user supplies
a large, positive or negative, value for xt->tm_year then the
calculation may overflow. If the user supplies an xt->tm_mon outside
the range 0-11 the function will read arbitrary memory.
How is the "user" going to do that? Do
"Roy T. Fielding" <[EMAIL PROTECTED]> writes:
> On Monday, March 22, 2004, at 04:00 PM, Philip Martin wrote:
>> This code in apr_time_exp_get:
>>
>> year = xt->tm_year;
>> if (year < 70 || ((sizeof(time_t) <= 4) && (year >= 138))) {
>> return APR_EBADDATE;
>> }
>>
>> rejects a
On Monday, March 22, 2004, at 04:00 PM, Philip Martin wrote:
This code in apr_time_exp_get:
year = xt->tm_year;
if (year < 70 || ((sizeof(time_t) <= 4) && (year >= 138))) {
return APR_EBADDATE;
}
rejects all 2038 dates even though all the 2038 dates up to
2038-01-19T03:14:07.00
This code in apr_time_exp_get:
year = xt->tm_year;
if (year < 70 || ((sizeof(time_t) <= 4) && (year >= 138))) {
return APR_EBADDATE;
}
rejects all 2038 dates even though all the 2038 dates up to
2038-01-19T03:14:07.00Z will fit into a 32-bit time_t.
apr_time_exp_gmt doesn
