[EMAIL PROTECTED] 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 (NO_GETTIMEOFDAY
et al.) throughout the application code in order to do time operations.
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.
Brian
