httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <brian.p...@cnet.com>
Subject Re: [Patch]: ap_cache_check_freshness 64 bit oddities
Date Sat, 12 Oct 2002 06:10:39 GMT
On Fri, 2002-10-11 at 16:04, Paul J. Reder wrote:
> I have run into a problem where the cache code randomly decides that a
> cached entry is stale or that the last modified date is some time in
> the future. I tracked it back to the ap_cache_check_freshness code
> which does a lot of checking of dates.
> 
> Some of this date checking code compares and assigns uncast numeric values
> (such as -1) and the output of atoi() to the apr_time_t values (which are
> long longs). The debugger showed me that only the bottom half of the
> apr_time_t was being updated/compared.
> 
> I would like to fix the code in the following ways (if there are no
> objections):
>     1) Replace the assignments/comparisons of 0 with APR_DATE_BAD
>     2) Have someone create a "#define APR_DATE_UNASSIGNED ((apr_time_t)-1)"
>            value in apr_date.h.
>     3) Replace the assignments/comparisons of -1 with APR_DATE_UNASSIGNED
>     4) Replace the atoi() calls with calls to apr_atoi64().

At first glance, I think there's an even more fundamental problem:
the code in ap_cache_check_freshness() appears to be mixing times
measured in microseconds (the result of ap_cache_current_age())
with times measured in seconds (everything that it gets from the
HTTP header).

Brian



Mime
View raw message