httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Wortham" <>
Subject Re: APR timestamps question
Date Tue, 17 Apr 2007 21:15:11 GMT
   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

   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,

On 4/13/07, William A. Rowe, Jr. <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message