William A. Rowe, Jr. wrote:
At 11:31 AM 7/11/2002, Brian Pane wrote:
I don't see a way to eliminate the "/ 1000" to convert usec to msec. But we may be able to do all the math in 32-bit mode, by limiting the maximum timeout to the number of milliseconds that will fit in 32 bits, which works out to a max timeout of about 50 days.
Actually, here is my current math, with optimized forms for specific
situations we encounter often (aprox. limits are given in the macro name).
They break down to;
apr_int32_t apr_time_sec_get(time) deprecates apr_time_sec(time) apr_int32_t apr_time_msec_get(time) deprecates apr_time_msec(time) apr_int32_t apr_time_usec_get(time) deprecates apr_time_usec(time) apr_int32_t apr_time_nsec_get(time) deprecates apr_time_nsec(time)
Oh no, I just recently finished changing all the code to use those now-deprecated macros. :-)
apr_int64_t apr_time_as_sec(time)
apr_int64_t apr_time_as_msec(time) or apr_time_as_272yrs_msec(time)
apr_int64_t apr_time_as_usec(time) or apr_time_as_3mos_usec(time)
apr_int64_t apr_time_as_nsec(time) or apr_time_as_2hrs_nsec(time)
The naming convention is way too subtle: apr_time_[unit]_get means 32-bit apr_time_as_[unit] means 64-bit
How often do you anticipate that people will be using the 32-bit versions? If it's not very often, then I'd rather just supply the 64-bit versions in the API, because those are the safe ones (no Y2038 problem). People who really need to do 32-bit math for performance reasons would have to cast explicitly, but IMHO that's good because it forces them to think more carefully about whether the loss of precision is safe.
--Brian
