Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 97151 invoked by uid 500); 13 Aug 2002 23:52:54 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 97114 invoked from network); 13 Aug 2002 23:52:53 -0000 Message-ID: <3D599BDB.7000901@apache.org> Date: Tue, 13 Aug 2002 16:52:59 -0700 From: Brian Pane User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@apr.apache.org Subject: Re: cvs commit: apr-site versioning.html References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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