"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
Jeff Trawick wrote:
Joe Orton wrote:
Updated patch attached, thanks for the feedback so far...
TODO:
* hook up Solaris sendfilev64 if necessary
looks necessary... dunno if there was a Solaris with sendfilev but no
sendfilev64 such that we'd have to thunk... for now I have this just for
playing
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
