William, Thanks much for the response. Your answers were exactly what I needed.
I know that APR was designed to be standard across all supported OSes and architectures so I was concerned when I read that a 64 bit integer used different placeholders with "printf" family of functions depending on what architecture the compiler was built for (sometimes "%llu" and sometimes "%lu"). I also considered testing for the actual type of typedef apr_time_t and using a #define to store the printf placeholder for type apr_time_t, but I now know that I would have been reinventing the wheel. I considered forcing a cast but I don't know what effect it would have on systems/environments I can't test with. Everything just fell into place once I started using APR_TIME_T_FMT. Thanks again William, Dave On 4/13/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
David Wortham wrote: > Sorry if this isn't the primary focus of this message-list, but I have a > general question about APR and timestamps (more about apr_int64_t). > > The typedef of apr_time_t is apr_int64_t. I assume this type is 64 bits > long on a 64 bit system. Is it 64 bits long on a 32bit (or smaller) > system? Yes. > The "printf" family of functions only seems to print out the correct number > using the "%llu" placeholder (in my 64bit experience). Will this > placeholder work gracefully with architectures less than 64bit? Will 64bit > and a 32bit modules will return the same string using "%llu"? No. > I found a lot of issues involving printing Probably - so did we. Which is why you will find APR_TIME_T_FMT. Alternately, factor into a forced (int) of the value / APR_USEC_PER_SEC.
-- David Wortham Senior Web Applications Developer Unspam Technologies, Inc. 1901 Prospector Dr. #30 Park City, UT 84060 (435) 513-0672
