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 21:19:00 GMT
A simple example of the disparity below...

At 02:31 PM 7/11/2002, you wrote:
>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_int64_t apr_time_as_sec(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.

Just as a trivial example of using apr_time_sec_get... it helps us
avoid casting over in the new poll/unix/poll.c line 164, where

         tv.tv_sec = apr_time_sec_get(timeout);

avoids a compiler emit that we are downcasting an in64 to a long.

>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