On Fri, Mar 22, 2019 at 6:58 AM <yla...@apache.org> wrote: > Author: ylavic > Date: Fri Mar 22 11:52:22 2019 > New Revision: 1856042 > > URL: http://svn.apache.org/viewvc?rev=1856042&view=rev > Log: > Use stdint types and inttypes formats when both available. > > Which should be the case on modern platforms, no change for others. > [...]
> + > # Now we need to find what apr_int64_t (sizeof == 8) will be. > -# The first match is our preference. > -if test "$ac_cv_sizeof_int" = "8"; then > +# The first match is our preference (use inttypes if available). > +APR_IFALLYES(header:stdint.h header:inttypes.h, hasinttypes="1", > hasinttypes="0") > +if test "$hasinttypes" = "1"; then > + int64_literal='#define APR_INT64_C(val) INT64_C(val)' > + uint64_literal='#define APR_UINT64_C(val) UINT64_C(val)' > + int64_t_fmt='#define APR_INT64_T_FMT PRId64' > + uint64_t_fmt='#define APR_UINT64_T_FMT PRIu64' > + uint64_t_hex_fmt='#define APR_UINT64_T_HEX_FMT PRIx64' > + int64_value="int64_t" > + uint64_value="uint64_t" > + APR_CHECK_TYPES_FMT_COMPATIBLE(int64_t, int, d, [ > + int64_strfn="strtoi" > + ], [ > + APR_CHECK_TYPES_FMT_COMPATIBLE(int64_t, long, ld, [ > + int64_strfn="strtol" > + ], [ > + APR_CHECK_TYPES_FMT_COMPATIBLE(int64_t, long long, lld, [ > + int64_strfn="strtoll" > + ], [ > + AC_ERROR([could not determine the string function for int64_t]) > + ])])]) > Overall, this is great work, thanks. Observation to Stefan, the apr_time_t type is unrelated to unix time_t, which measured seconds, not our usec, where we determined that the fastest 64-bit-or-longer int is the appropriate type to store all dates that interest us this century and beyond. This change locks us down a little further, to an exactly 64 bit int, but I see no harm in that today, and no issues with leveraging stdint to accomplish this for explicitly 8-byte int storage. In the else-thread, I offered a redirect to a thread with caveat to be cautious about, down this rabbit hole. Richard explained in that see-other thread; > On Wed, Oct 10, 2012 at 9:34 PM, Richard Smith <[hidden email]> wrote: > > > > libc++ does this to pick up the macro definitions: > > > > #include <inttypes.h> > > > > However, glibc's inttypes.h only provides them in C++ mode if _STDC_FORMAT_MACROS is defined, and libc++ doesn't define it. > > Sorry, needs more underscore: __STDC_FORMAT_MACROS. You cannot assume that inttypes.h gave you the c99 format macros by simply testing for inttypes.h, in fact earlier pre-c99 drafts of inttypes.h may have provided fixed types with no format macros whatsoever. I'd think we mean to first keep the type mappings by d/ld/lld, ahead of then overriding these when we confirm PRI$64 macros are available? APR_CHECK_TYPES_FMT_COMPATIBLE makes quick work of this.
