httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: [PATCH] ab cleanups...
Date Wed, 11 Apr 2001 18:30:42 GMT
LLONG_MAX is not defined on Windows. And I still get 16 warning message, about
the same as before applying the patch.


> On Wed, Apr 11, 2001 at 12:11:02AM -0400, Cliff Woolley wrote:
> > apr_time_t (64 bits) is reserved for values that represent time *in
> > microseconds* from Jan 1, 1970.  Time offsets in microseconds can be
> > represented with apr_interval_time_t (64 bits) or
> > apr_short_interval_time_t (32 bits).
> Ah, now that I look at it, I also used apr_off_t incorrectly.  I'm not even
> sure why I used apr_off_t.  Switched to apr_interval_time_t where
> appropriate.  I guess I was thinking of file offsets, not time offsets.
> > If you want to represent absolute time or relative (interval) time in
> > seconds or milliseconds, you should just use apr_int64_t or apr_int32_t.
> Is using apr_int64_t preferred to using apr_interval_time_t?  Also,
> wouldn't there be some problems if you take an apr_time_t and subtract
> another apr_time_t and stick the result in a 32-bit value?  This is what
> was implicitly happening on Solaris/Sparc - which caused all of the
> calculations to go haywire.
> > Alternatively, you could rearrange the conversions to/from microseconds in
> > your code so that the values are stored and manipulated in microseconds
> > (in which case the use of apr_time_t and apr_interval_time_t are fine) and
> > you don't convert to seconds/milliseconds until "the last minute" (eg,
> > when you go to print out the results).
> Parts of ab do this, and parts don't.  Some of the calculations are done
> as it happens and some of them are delayed until after the run.  It wasn't
> my intention to rework ab - just get it working again.

View raw message