> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] > > Then how about apr_buseconds_t? This makes it absolutely clear that the > type contains some number of buseconds [whatever those are... open the > doxygen pages... ah... +/-number of binary microseconds.] But the fact > is the type is clearly some number of seconds, therefore an interval.
Some number of seconds does NOT indicate an interval. Also, why is that in seconds all of a sudden? Our current apr_interval_time_t are in usecs.
I said, apr_buseconds_t. Meaning an arbitrary number of binary microseconds. And some number of binary microseconds can translate into a timeout or any other interval of time.
I'm really confused here; there are two principal expressions of time. One is not
anchored to any specific epoch; that's a delta. One is anchored to a specific
epoch, such as 1/1/1970.
Can we start this conversation over completely? Currently we are arguing over names for a new type, but I don't think we actually know the problem that we are trying to solve.
If it is just performance, then keep the current name. Add a versioning component to APR, and force people to look at their code by using the versioning component.
That is your opinion. There are other opinions expressed on the list. Their arguments have equal merit.
If it is confusion with time_t, then IMNSHO, that is a bogus argument. The bugs that were in Apache were there because nobody ever looked at the code, it was just assumed that it was correct. Anybody writing code from scratch shouldn't have the problem.
No, folks will have that problem if they've coded against ANSI/POSIX/C99 for years. Adding apr_busec_time_t and apr_busec_interval_t [or whatever the f we decide to name them] absolutely dictates that these are not your Grandpa's time_t units.
Bill
