You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2011/01/17 21:58:37 UTC

Weird weirdness with %lld and apr_psprintf

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!

Re: Weird weirdness with %lld and apr_psprintf

Posted by Jim Jagielski <ji...@jaguNET.com>.
Fixed in r1060104/1060105/1060106

On Jan 17, 2011, at 4:24 PM, Jim Jagielski wrote:

> 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!
>> 
> 


Re: Weird weirdness with %lld and apr_psprintf

Posted by Jim Jagielski <ji...@jaguNET.com>.
Fixed in r1060104/1060105/1060106

On Jan 17, 2011, at 4:24 PM, Jim Jagielski wrote:

> 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!
>> 
> 


Re: Weird weirdness with %lld and apr_psprintf

Posted by Jim Jagielski <ji...@apache.org>.
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!
> 


Re: Weird weirdness with %lld and apr_psprintf

Posted by Jim Jagielski <ji...@apache.org>.
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!
>