apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: apr_time_t --> apr_time_usec_t
Date Mon, 10 Jun 2002 22:40:14 GMT
This is going to break EVERY apr app out there.  I have no problem with
the change, but everything is going to be broken.  Is there any way to
do this by creating an apr_time32_t, or something that will keep the
default at 64-bit, and allow people to use 32 if they specify it?

I did a quick search, Dean didn't mention why he made the change to
64-bit back when he committed the code in 2000, and there doesn't seem
to have been a conversation about it at the time.


Ryan Bloom                  rbb@covalent.net
645 Howard St.              rbb@apache.org
San Francisco, CA 

> -----Original Message-----
> From: Brian Pane [mailto:brian.pane@cnet.com]
> Sent: Monday, June 10, 2002 3:39 PM
> To: dev@apr.apache.org
> Subject: Re: apr_time_t --> apr_time_usec_t
> Roy T. Fielding wrote:
> > I am tired of seeing this stupid change to the semantics of time_t
> > under Unix continue to cause bugs in every project that uses APR.
> > apr_time_t must be in seconds.  If folks want APR to keep time in
> > microseconds, then they had bloody well change the type name
> > accordingly.
> +1.  I'm tired of taking the perfomance hit of
> 64-bit divisions on 32-bit CPUs to retrieve the
> time_t.
> In order to fix it, though, we'd really need to change
> the implementation in some way that breaks old code at
> compile time.  Otherwise, if apr_time_t remains a 64-bit
> int but its meaning changes by a factor of a million, lots
> of bugs in people's APR-based apps aren't going to show up
> until runtime.
> > I know of one existing bug in httpd that I would consider a
> > showstopper, if I were RM, due to the way APR handles time.
> > In order to fix it, I am going to need to reinstate handling
> > of time in seconds, even if that means abandoning APR's routines.
> Don't keep us in suspense...what's the bug?!  :-)
> --Brian

View raw message