Re: apr_time_t -- apr_time_usec_t

2002-06-12 Thread William A. Rowe, Jr.
At 10:14 PM 6/10/2002, Brian Pane wrote: William A. Rowe, Jr. wrote: At 09:31 PM 6/10/2002, I wrote: usec * 1048575 / 100 = busec bsec * 100 / 1048575 = usec whoops, s/1048575/1048576/ That's a major improvement. I was going to complain about the need for both a 64-bit multiplication and

Re: apr_time_t -- apr_time_usec_t

2002-06-12 Thread Cliff Woolley
On Tue, 11 Jun 2002, William A. Rowe, Jr. wrote: However, we aught to define convenience macros; #define APR_BUSEC_PER_SEC 1048576 I was thinking the same thing. +1. --Cliff

Re: apr_time_t -- apr_time_usec_t

2002-06-11 Thread Brian Pane
Justin Erenkrantz wrote: Ryan Bloom wrote: This is going to break EVERY apr app out there. I have no problem with the change, but everything is going to be broken. Is there any way to do this by creating an apr_time32_t, or something that will keep the default at 64-bit, and allow people to use

Re: apr_time_t -- apr_time_usec_t

2002-06-11 Thread William A. Rowe, Jr.
At 05:04 PM 6/10/2002, you wrote: I am tired of seeing this stupid change to the semantics of time_t under Unix continue to cause bugs in every project that uses APR. I must have missed that discussion traveling. Pointers please? apr_time_t must be in seconds. If folks want APR to keep time in

Re: apr_time_t -- apr_time_usec_t

2002-06-11 Thread Aaron Bannert
On Mon, Jun 10, 2002 at 03:57:29PM -0700, Justin Erenkrantz wrote: How about using the value we already have: typedef apr_int32_t apr_short_interval_time_t; Unfortunately, that type still has units of milliseconds. Seems like Roy needs an apr_seconds_t, and apr_short_interval_time_t should

Re: apr_time_t -- apr_time_usec_t

2002-06-11 Thread Aaron Bannert
On Mon, Jun 10, 2002 at 04:14:14PM -0700, Aaron Bannert wrote: Unfortunately, that type still has units of milliseconds. Seems like Roy needs an apr_seconds_t, and apr_short_interval_time_t should be renamed apr_milliseconds_t. er, s/milliseconds/microseconds/ -aaron

Re: apr_time_t -- apr_time_usec_t

2002-06-11 Thread Roy T. Fielding
On Monday, June 10, 2002, at 04:11 PM, William A. Rowe, Jr. wrote: At 05:04 PM 6/10/2002, you wrote: I am tired of seeing this stupid change to the semantics of time_t under Unix continue to cause bugs in every project that uses APR. I must have missed that discussion traveling. Pointers please?

Re: apr_time_t -- apr_time_usec_t

2002-06-11 Thread Jim Jagielski
William A. Rowe, Jr. wrote: apr_time_t must be in seconds. If folks want APR to keep time in microseconds, then they had bloody well change the type name accordingly. apr_time_t must nothing :-) Let's discuss *should(s)* time_t is seconds. I love the idea of apr_time_usec_t and

Re: apr_time_t -- apr_time_usec_t

2002-06-11 Thread William A. Rowe, Jr.
At 09:15 PM 6/10/2002, you wrote: William A. Rowe, Jr. wrote: apr_time_t must be in seconds. If folks want APR to keep time in microseconds, then they had bloody well change the type name accordingly. apr_time_t must nothing :-) Let's discuss *should(s)* time_t is seconds. I love the

Re: apr_time_t -- apr_time_usec_t

2002-06-11 Thread William A. Rowe, Jr.
At 09:31 PM 6/10/2002, I wrote: usec * 1048575 / 100 = busec bsec * 100 / 1048575 = usec whoops, s/1048575/1048576/

Re: apr_time_t -- apr_time_usec_t

2002-06-11 Thread Brian Pane
William A. Rowe, Jr. wrote: At 09:31 PM 6/10/2002, I wrote: usec * 1048575 / 100 = busec bsec * 100 / 1048575 = usec whoops, s/1048575/1048576/ That's a major improvement. I was going to complain about the need for both a 64-bit multiplication and a 64-bit division to do the

Re: apr_time_t -- apr_time_usec_t

2002-06-10 Thread Cliff Woolley
On Mon, 10 Jun 2002, Roy T. Fielding wrote: I know of one existing bug in httpd that I would consider a showstopper, if I were RM, due to the way APR handles time. Are you going to tell me what it is? :)

Re: apr_time_t -- apr_time_usec_t

2002-06-10 Thread Brian Pane
Roy T. Fielding wrote: I am tired of seeing this stupid change to the semantics of time_t under Unix continue to cause bugs in every project that uses APR. apr_time_t must be in seconds. If folks want APR to keep time in microseconds, then they had bloody well change the type name accordingly.

RE: apr_time_t -- apr_time_usec_t

2002-06-10 Thread Ryan Bloom
. [EMAIL PROTECTED] San Francisco, CA -Original Message- From: Brian Pane [mailto:[EMAIL PROTECTED] Sent: Monday, June 10, 2002 3:39 PM To: dev@apr.apache.org Subject: Re: apr_time_t -- apr_time_usec_t Roy T. Fielding wrote: I am tired of seeing this stupid change to the semantics

Re: apr_time_t -- apr_time_usec_t

2002-06-10 Thread Brian Pane
Ryan Bloom wrote: This is going to break EVERY apr app out there. I have no problem with the change, but everything is going to be broken. Is there any way to do this by creating an apr_time32_t, or something that will keep the default at 64-bit, and allow people to use 32 if they specify it?

Re: apr_time_t -- apr_time_usec_t

2002-06-10 Thread Justin Erenkrantz
Ryan Bloom wrote: This is going to break EVERY apr app out there. I have no problem with the change, but everything is going to be broken. Is there any way to do this by creating an apr_time32_t, or something that will keep the default at 64-bit, and allow people to use 32 if they specify it?