apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From field...@apache.org
Subject cvs commit: apr STATUS
Date Thu, 11 Jul 2002 23:32:50 GMT
fielding    2002/07/11 16:32:50

  Modified:    .        STATUS
  wake up
  Revision  Changes    Path
  1.142     +35 -3     apr/STATUS
  Index: STATUS
  RCS file: /home/cvs/apr/STATUS,v
  retrieving revision 1.141
  retrieving revision 1.142
  diff -u -r1.141 -r1.142
  --- STATUS	11 Jul 2002 23:00:54 -0000	1.141
  +++ STATUS	11 Jul 2002 23:32:50 -0000	1.142
  @@ -61,13 +61,18 @@
       * apr_time_t will change to use binary microseconds based on
         profiling.  The last remaining question on the table is keeping
         the apr_time_t designation, or changing the symbol name.
  -      1) Keeping the existing apr_time_t names, in spite of potential
  -         ANSI/C99 time_t confusion.  apr_types don't promise to be
  +      1) Keeping the existing apr_time_t names, in spite of
  +         ANSI/C99 time_t confusion demonstrated by dozens of bug
  +         fixes since it was introduced.  apr_types don't promise to be
            system types, or map to system units.
            +1: rbb, wrowe, jerenkrantz, striker
            +0: brianp
            -0.5: jwoolley
            -1: aaron [veto for reusing the apr_time_t identifier for a new use]
  +             fielding [if they don't map to system types, then don't mimic
  +               the system types --- give me back all of my ap_time functions
  +               that were converted to microsecond arguments even though none
  +               of them do anything useful with microseconds.]
         2) Renaming the function to get rid of apr_time_t vs time_t confusion,
            which brianp suggests apr_timeval_t.
            +1: fielding, aaron
  @@ -78,6 +83,33 @@
                          vetoed whatever that was]
            -0: wrowe, jerenkrantz, striker
            -0.5: rbb
  +      [fielding: Is APR time guaranteed to be a scalar quantity?  If so,
  +       then we must include units as part of the definition of the
  +       type in order to let developers make use of that quarantee.
  +       In that case, the units should be in the type name [e.g., apr_busec].
  +       If not, then we should be storing time in a structure with
  +       separate fields in order to have better precision with less code.
  +       In any case, time_t ==> seconds because time_t is guaranteed
  +       by POSIX to be a scalar quantity for arithmetic operations.
  +       Saying that apr_time_t doesn't imply seconds is to ignore the
  +       fact that all of those httpd functions used to create APR were
  +       defined in terms of seconds and make no use of microseconds.
  +       Meanwhile, the only reason we have this stupid debate is because
  +       wrowe insists that time_t is 32 bits and therefore dies in 2038.
  +       In fact, time_t is 64 bits on 64bit NT, Linux, OSF, and probably
  +       others that I haven't checked.  In any case, since we use the
  +       system's time_t time() function to get the time value everywhere
  +       except Win32 w/SYSTEMTIME, we only ever have a resolution of
  +       seconds or milliseconds.  So, why the hell are we storing usecs?
  +       We don't use them.  We don't even have display functions for them.
  +       We have to do a stupid conversion every time we actually do something
  +       useful with time in order to support somebody's wet dream of a
  +       potentially useful feature?  That's crap!  This is exactly why
  +       I hate portability libraries that aren't based on the demonstrated
  +       needs of a specific application.]

View raw message