Copied to the APR list, since this is an APR type. The original
proposal by Roy was to make apr_time_t a structure containing a
time_t for seconds, and an int for microseconds, since many/most
users of this type only need 1-second resolution, and the ones that
need microsecond resolution need microseconds as a separate parameter.
At 02:37 PM 02/23/2001 -0800, Roy T. Fielding wrote:
> > time arithmetic is way easier on a single scalar than it is on
> multiple
> > scalars. contrast:
> >
> > diff = now - then;
> >
> > vs.
> >
> > diff.sec = now.sec - then.sec;
> > long tmp = (long)now.usec - (long)then.usec;
> > if (tmp < 0) {
> > tmp += 1000000;
> > --diff.sec;
> > }
> > diff.usec = tmp;
>
>No, contrast
>
> diff = apr_time_interval(then, now);
>
>apr_time_t is a data type. The above can be a macro if you want it
>fast, but the point is that every single client of APR should not be
>dependent on knowing the exact representation of time and
>remembering that they have to divide it by 100000 just to get
>something useful.
Especially since they have to divide it by 1,000,000, not 100,000.
>I have seen well over 30 commits fixing bugs specifically due to
>this notion that you can subtract one unknown scalar from another
>unknown scalar and still remain within the bounds of some other
>unknown scalar. And another 20 or so fixing places where someone
>forgot to divide by or multiply by 100000.
... or when they divided by the wrong number because they dropped a
zero.
I agree that this would be a good change.
--
Greg Marr
[EMAIL PROTECTED]
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"
