apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PATCH 3] example binary BUSEC for discussion
Date Thu, 11 Jul 2002 19:31:22 GMT
At 02:13 PM 7/11/2002, Brian Pane wrote:
>William A. Rowe, Jr. wrote:
>>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. :-)

I know... but there are two different 'things'...

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

WRONG! apr_time_msec_get(time) gets the fractional component
of time... e.g. 32500.15 seconds would return 150 msecs..

apr_time_as_msec returns the entire time value!  So we end up with
a time of 32,500,150 in msec's.  That's why these are int64.

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

The 32bit flavor of sec, vs. a 64 bit flavor is a simple way of
avoiding casts in the user's code.  I'm only asking for the number
of seconds in an apr_time_t in order to set a time, calculate a
difference, etc.  But I don't care too much, one way or the other.

apr_time_as_sec gives me a HUGE number of seconds to work
with as an absolute time from 1/1/70.  That must remain 64bit.


View raw message