apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@apache.org
Subject Re: cvs commit: apr-site versioning.html
Date Wed, 14 Aug 2002 00:01:53 GMT
yOn Tue, 13 Aug 2002, Brian Pane wrote:

> rbb@apache.org wrote:
> >>To use time_t in a portable app, though, I expect that we'll still
> >>need to rely on APR to provide a portability wrapper.  The code for
> >>even simple things like getting the current time is different between
> >>Unix and Win32.   (I wouldn't mind leaving apr_time_t as-is if we
> >>also had a portable second-resolution time API to complement it.)
> >>    
> >>
> >
> >I'm sorry, but that just isn't true.  Apache 1.3 had no problem with time
> >function portability.
> >
> Sure it did.  Apache 1.3 had to use platform-specific ifdefs 
> et al.) throughout the application code in order to do time operations.

Yep, you are correct, when Apache 1.3 wanted microseconds we needed
portability code to acheive that.  However, when Apache 1.3 wanted
seconds, it just used time(), without any #ifdefs.  Since APR is now
providing the microsecond logic, we only need to be concerned with
seconds, which is standardized as a part of POSIX.

> >  POSIX requires a certain number of time functions
> >that can be used with time_t variables.  APR and Apache both require ANSI
> >compilers and C libraries.  There is no reason to wrap the time_t
> >structure that I can think of.
> >
> The structure isn't the problem (though we may want to wrap it to
> guarantee that it's at least 64 bits for Y2038 reasons).  It's the
> functions that will give us portability problems.

No, we don't want to wrap it at all.  We want to use 32-bits on 32-bit
platforms, and 64-bits on 64-bit platforms.  Wrapping the structure is
what got us into the current mess.

Again, if you want microseconds, use apr_time_t.  If you want seconds, use
time_t.  In both cases the functions are standardized and portable.


Ryan Bloom                        	rbb@apache.org
550 Jean St
Oakland CA 94610

View raw message