Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Message-ID: <058801c0c2b5$8443d140$e4421b09@raleigh.ibm.com>
From: "Bill Stoddard" <bill@wstoddard.com>
To: <new-httpd@apache.org>
References: <20010410203010.B10042@ebuilt.com>
 <Pine.GSO.4.32.0104110003010.5911-100000@cobra.cs.Virginia.EDU>
 <20010410220114.D10042@ebuilt.com>
Subject: Re: [PATCH] ab cleanups...
Date: Wed, 11 Apr 2001 14:30:42 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

LLONG_MAX is not defined on Windows. And I still get 16 warning message, about
the same as before applying the patch.

Bill

> 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.
>