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.
