You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Neil Conway <nr...@cs.berkeley.edu> on 2009/09/15 23:03:51 UTC
OFF_T_FMT issue on OSX 10.6
% cd test
% ./testall -v testfmt
testfmt : \Line 52: expected <0>, but saw <%ld>
FAILED 1 of 9
The failing test covers apr_off_t's format sequence:
sprintf(buf, "%" APR_OFF_T_FMT, var);
ABTS_STR_EQUAL(tc, "0", buf);
apr_snprintf(buf, sizeof(buf), "%" APR_OFF_T_FMT, var);
ABTS_STR_EQUAL(tc, "0", buf);
The sprintf() succeeds, but the apr_snprintf() fails. The relevant
defines from apr.h are:
#define APR_SSIZE_T_FMT "ld"
#define APR_SIZE_T_FMT "lu"
#define APR_OFF_T_FMT "lld"
#define APR_PID_T_FMT "d"
#define APR_INT64_T_FMT "ld"
The system off_t is defined as int64_t, so choosing a different format
sequence for int64_t and off_t seems wrong to begin with. So this
coding in configure.in is probably sub-optimal (circa line 1616):
# Per OS tuning...
case $host in
*apple-darwin10.*)
# off_t is a long long, but long == long long
if test "$ac_cv_sizeof_long" = "$ac_cv_sizeof_long_long"; then
off_t_fmt='#define APR_OFF_T_FMT "lld"'
fi
;;
esac
But I believe the actual bug is due to the coding at
apr_snprintf.c:816 (on 1.3 branch) -- at a glance, it seems to get
rather confused whenever "%lld" is given but APR_INT64_T_FMT is
"%ld"...
Neil