I think it is related to OS X and vformatter:
if ((sizeof(APR_INT64_T_FMT) == 4 &&
fmt[0] == APR_INT64_T_FMT[0] &&
fmt[1] == APR_INT64_T_FMT[1]) ||
(sizeof(APR_INT64_T_FMT) == 3 &&
fmt[0] == APR_INT64_T_FMT[0]) ||
(sizeof(APR_INT64_T_FMT) > 4 &&
strncmp(fmt, APR_INT64_T_FMT,
sizeof(APR_INT64_T_FMT) - 2) == 0)) {
/* Need to account for trailing 'd' and null in sizeof() */
var_type = IS_QUAD;
fmt += (sizeof(APR_INT64_T_FMT) - 2);
}
else if (*fmt == 'q') {
var_type = IS_QUAD;
fmt++;
}
else if (*fmt == 'l') {
var_type = IS_LONG;
fmt++;
}
under OS X, 64bit, APR_INT64_T_FMT is 'ld' and APR_OFF_T_FMT is 'lld'...
In fact, I'm sure it is... Looking over the archives, I see a few
patches floating around for this...
On Jan 17, 2011, at 3:58 PM, Jim Jagielski wrote:
> OK, I was getting some weird weird errors with the byterange tests
> for httpd... it was always failing. Looking over the output, what
> I was seeing is that the output was sending out, well... see the below:
>
> # Failed test 149 in t/apache/byterange.t at line 52 fail #149
> Range: bytes=0-8192
> Content-Range: bytes %ld-%ld/%ld
>
> This is when APR_OFF_T_FMT is "lld"
>
> No look at this... I change the section of code in byterange_filter.c
> to:
> if (ctx->num_ranges == 1) {
> apr_table_setn(r->headers_out, "Content-Range",
> apr_psprintf(r->pool, "bytes %lld - %lld / %lld",
> range_start, range_end, clength));
>
> and I get *this*!
>
> # Failed test 149 in t/apache/byterange.t at line 52 fail #149
> Range: bytes=0-8192
> Content-Range: bytes %ld - %ld / %ld
>
> Note that it looks like something is compressing %lld to %ld!
>
