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
(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
|