apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: more notes on the apr_time_t issue
Date Sun, 14 Jul 2002 20:41:15 GMT
Aaron Bannert wrote:

>On Sun, Jul 14, 2002 at 04:01:35PM -0400, Cliff Woolley wrote:
>>And while apr_time_busec_t is a bit better than apr_utime_t, I agree
>>people will say "wtf is a busec".  And it means we'd have to rename all
>>our time functions for no good reason.  "apr_time_now" just makes so much
>>sense.  "apr_time_t" makes so much sense.  That's just got to be it.
>The whole problem here (and this is where I completely agree with you
>all) is that apr_time_t is the perfect name for the time system in APR.
>It's just that if we change out the implementation w/o the ability to
>break at dynamic link-time, then there will be huge problems.
>>How to resolve Aaron's veto?  The #ifndef NEW_TIME_FMT thing is
>>interesting.  :)
>How does that help me though? Wouldn't that mean that APR would be linked
>with the new time implementation and the older app would link in just
>fine even though the representation had changed?

In practical terms, there's almost nothing that will keep people
from using old binaries with a new libapr, short of intentionally
changing the name of some commonly called function to ensure that
the run-time linker fails.

Changing the type name won't help, as we've discussed before, so
I don't think that the binary compatibility issues are a legitimate
tie-breaker for choosing the new type name.


View raw message