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