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 ---------------------------------------------- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA > -----Original Message----- > From: Brian Pane [mailto:[EMAIL PROTECTED] > 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 >
