You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Chris Knight <Ch...@nasa.gov> on 2010/08/11 17:51:48 UTC
%lld/%llu not handled by apr_vformatter
I spent half-a-day yesterday trying to figure out why I was crashing in apr_psprintf on a strlen until I realized that my "%llu%s" format string was causing it to use my long long int as a char *.
Needless to say, no harm in adding support for %ll[du] yes?
Ah, 64-bit fun for everyone....
Example code:
#include <apr.h>
#include <apr_pools.h>
#include <apr_strings.h>
#include <stdio.h>
int main(int argc, char **argv) {
apr_pool_t *pool = NULL;
char *s = "hello world"; u_int64_t v = 12345678;
apr_pool_initialize(); apr_pool_create(&(pool), NULL);
printf("%llu%s", v, s); // works
char *f = apr_psprintf(pool, "%llu%s", v, s); // segfault on strlen
printf("%s\n", f);
}
Re: %lld/%llu not handled by apr_vformatter
Posted by Dan Poirier <po...@pobox.com>.
Patches are always welcome. See <http://apr.apache.org/patches.html>.
Usually it's better to add them to a bug report than send them to the
list, so they don't get lost.
On 2010-08-11 at 12:12, Chris Knight <ch...@nasa.gov> wrote:
> Thanks for the pointer.
>
> While I understand the APR team wants to match APR_INT64_T_FMT, %ll[du] should still be supported even if APR_INT64_T_FMT is "ld", to ensure compatibility with the system printf.
>
> (APR team, I'd be happy to become a committer and/or submit patches, if y'all are receptive.)
>
> On Aug 11, 2010, at 9:02 AM, Hyrum K. Wright wrote:
>
>> Unfortunately, you seem to have found the same bug I uncovered in March:
>> http://mail-archives.apache.org/mod_mbox/apr-dev/201003.mbox/%3Cb51ffb6f1003100926n22c1dd79id9696972b23a153a@mail.gmail.com%3E
>>
>> To my knowledge it hasn't been fixed, thought that thread does include
>> a somewhat hacky patch to work around the issue. Perhaps it will be
>> of use to you.
>>
>> -Hyrum
>>
>> On Wed, Aug 11, 2010 at 10:51 AM, Chris Knight
>> <Ch...@nasa.gov> wrote:
>>> I spent half-a-day yesterday trying to figure out why I was crashing in apr_psprintf on a strlen until I realized that my "%llu%s" format string was causing it to use my long long int as a char *.
>>>
>>> Needless to say, no harm in adding support for %ll[du] yes?
>>>
>>> Ah, 64-bit fun for everyone....
>>>
>>> Example code:
>>>
>>> #include <apr.h>
>>> #include <apr_pools.h>
>>> #include <apr_strings.h>
>>> #include <stdio.h>
>>>
>>> int main(int argc, char **argv) {
>>> apr_pool_t *pool = NULL;
>>> char *s = "hello world"; u_int64_t v = 12345678;
>>>
>>> apr_pool_initialize(); apr_pool_create(&(pool), NULL);
>>> printf("%llu%s", v, s); // works
>>> char *f = apr_psprintf(pool, "%llu%s", v, s); // segfault on strlen
>>> printf("%s\n", f);
>>> }
Re: %lld/%llu not handled by apr_vformatter
Posted by Chris Knight <ch...@nasa.gov>.
Thanks for the pointer.
While I understand the APR team wants to match APR_INT64_T_FMT, %ll[du] should still be supported even if APR_INT64_T_FMT is "ld", to ensure compatibility with the system printf.
(APR team, I'd be happy to become a committer and/or submit patches, if y'all are receptive.)
On Aug 11, 2010, at 9:02 AM, Hyrum K. Wright wrote:
> Unfortunately, you seem to have found the same bug I uncovered in March:
> http://mail-archives.apache.org/mod_mbox/apr-dev/201003.mbox/%3Cb51ffb6f1003100926n22c1dd79id9696972b23a153a@mail.gmail.com%3E
>
> To my knowledge it hasn't been fixed, thought that thread does include
> a somewhat hacky patch to work around the issue. Perhaps it will be
> of use to you.
>
> -Hyrum
>
> On Wed, Aug 11, 2010 at 10:51 AM, Chris Knight
> <Ch...@nasa.gov> wrote:
>> I spent half-a-day yesterday trying to figure out why I was crashing in apr_psprintf on a strlen until I realized that my "%llu%s" format string was causing it to use my long long int as a char *.
>>
>> Needless to say, no harm in adding support for %ll[du] yes?
>>
>> Ah, 64-bit fun for everyone....
>>
>> Example code:
>>
>> #include <apr.h>
>> #include <apr_pools.h>
>> #include <apr_strings.h>
>> #include <stdio.h>
>>
>> int main(int argc, char **argv) {
>> apr_pool_t *pool = NULL;
>> char *s = "hello world"; u_int64_t v = 12345678;
>>
>> apr_pool_initialize(); apr_pool_create(&(pool), NULL);
>> printf("%llu%s", v, s); // works
>> char *f = apr_psprintf(pool, "%llu%s", v, s); // segfault on strlen
>> printf("%s\n", f);
>> }
Re: %lld/%llu not handled by apr_vformatter
Posted by Chris Knight <ch...@nasa.gov>.
How does libc do printf for %lld for universal binaries?
On Aug 11, 2010, at 11:38 AM, Jim Jagielski wrote:
> Universal binaries for OS X and APR are not supported. I must
> force either 32 or 64 bit... Attempts to fix this at the
> APR level have been vetoed and so no further effort can
> be done.
>
> The long and short of it (no pun intended) is that under
> OS X and universal binaries, you can no longer have
> some type lengths statically defined in *.h files as
> being a certain number of bits. Instead, the APR *.h files
> would require some internal #if tests which "looks" to see
> how the package is being compiled and then selects the
> correct set of bit sizes... This was deemed "too ugly"
> and was vetoed.
>
> For hints, I would encourage people to see how MacPorts
> works around this...
>
> On Aug 11, 2010, at 12:02 PM, Hyrum K. Wright wrote:
>
>> Unfortunately, you seem to have found the same bug I uncovered in March:
>> http://mail-archives.apache.org/mod_mbox/apr-dev/201003.mbox/%3Cb51ffb6f1003100926n22c1dd79id9696972b23a153a@mail.gmail.com%3E
>>
>> To my knowledge it hasn't been fixed, thought that thread does include
>> a somewhat hacky patch to work around the issue. Perhaps it will be
>> of use to you.
>>
>> -Hyrum
>>
>> On Wed, Aug 11, 2010 at 10:51 AM, Chris Knight
>> <Ch...@nasa.gov> wrote:
>>> I spent half-a-day yesterday trying to figure out why I was crashing in apr_psprintf on a strlen until I realized that my "%llu%s" format string was causing it to use my long long int as a char *.
>>>
>>> Needless to say, no harm in adding support for %ll[du] yes?
>>>
>>> Ah, 64-bit fun for everyone....
>>>
>>> Example code:
>>>
>>> #include <apr.h>
>>> #include <apr_pools.h>
>>> #include <apr_strings.h>
>>> #include <stdio.h>
>>>
>>> int main(int argc, char **argv) {
>>> apr_pool_t *pool = NULL;
>>> char *s = "hello world"; u_int64_t v = 12345678;
>>>
>>> apr_pool_initialize(); apr_pool_create(&(pool), NULL);
>>> printf("%llu%s", v, s); // works
>>> char *f = apr_psprintf(pool, "%llu%s", v, s); // segfault on strlen
>>> printf("%s\n", f);
>>> }
>>
>
Re: %lld/%llu not handled by apr_vformatter
Posted by Jim Jagielski <ji...@jaguNET.com>.
Universal binaries for OS X and APR are not supported. I must
force either 32 or 64 bit... Attempts to fix this at the
APR level have been vetoed and so no further effort can
be done.
The long and short of it (no pun intended) is that under
OS X and universal binaries, you can no longer have
some type lengths statically defined in *.h files as
being a certain number of bits. Instead, the APR *.h files
would require some internal #if tests which "looks" to see
how the package is being compiled and then selects the
correct set of bit sizes... This was deemed "too ugly"
and was vetoed.
For hints, I would encourage people to see how MacPorts
works around this...
On Aug 11, 2010, at 12:02 PM, Hyrum K. Wright wrote:
> Unfortunately, you seem to have found the same bug I uncovered in March:
> http://mail-archives.apache.org/mod_mbox/apr-dev/201003.mbox/%3Cb51ffb6f1003100926n22c1dd79id9696972b23a153a@mail.gmail.com%3E
>
> To my knowledge it hasn't been fixed, thought that thread does include
> a somewhat hacky patch to work around the issue. Perhaps it will be
> of use to you.
>
> -Hyrum
>
> On Wed, Aug 11, 2010 at 10:51 AM, Chris Knight
> <Ch...@nasa.gov> wrote:
>> I spent half-a-day yesterday trying to figure out why I was crashing in apr_psprintf on a strlen until I realized that my "%llu%s" format string was causing it to use my long long int as a char *.
>>
>> Needless to say, no harm in adding support for %ll[du] yes?
>>
>> Ah, 64-bit fun for everyone....
>>
>> Example code:
>>
>> #include <apr.h>
>> #include <apr_pools.h>
>> #include <apr_strings.h>
>> #include <stdio.h>
>>
>> int main(int argc, char **argv) {
>> apr_pool_t *pool = NULL;
>> char *s = "hello world"; u_int64_t v = 12345678;
>>
>> apr_pool_initialize(); apr_pool_create(&(pool), NULL);
>> printf("%llu%s", v, s); // works
>> char *f = apr_psprintf(pool, "%llu%s", v, s); // segfault on strlen
>> printf("%s\n", f);
>> }
>
Re: %lld/%llu not handled by apr_vformatter
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Unfortunately, you seem to have found the same bug I uncovered in March:
http://mail-archives.apache.org/mod_mbox/apr-dev/201003.mbox/%3Cb51ffb6f1003100926n22c1dd79id9696972b23a153a@mail.gmail.com%3E
To my knowledge it hasn't been fixed, thought that thread does include
a somewhat hacky patch to work around the issue. Perhaps it will be
of use to you.
-Hyrum
On Wed, Aug 11, 2010 at 10:51 AM, Chris Knight
<Ch...@nasa.gov> wrote:
> I spent half-a-day yesterday trying to figure out why I was crashing in apr_psprintf on a strlen until I realized that my "%llu%s" format string was causing it to use my long long int as a char *.
>
> Needless to say, no harm in adding support for %ll[du] yes?
>
> Ah, 64-bit fun for everyone....
>
> Example code:
>
> #include <apr.h>
> #include <apr_pools.h>
> #include <apr_strings.h>
> #include <stdio.h>
>
> int main(int argc, char **argv) {
> apr_pool_t *pool = NULL;
> char *s = "hello world"; u_int64_t v = 12345678;
>
> apr_pool_initialize(); apr_pool_create(&(pool), NULL);
> printf("%llu%s", v, s); // works
> char *f = apr_psprintf(pool, "%llu%s", v, s); // segfault on strlen
> printf("%s\n", f);
> }
Re: %lld/%llu not handled by apr_vformatter
Posted by Chris Knight <Ch...@nasa.gov>.
I am on 64-bit, %lu works just fine. My problem is that %llu on my 64-bit OS causes apr_vformatter to not identify %llu as a "%" string, so that in my example below it skips the %llu and sends the u_int64_t to the %s, causing a seg fault. Whereas printf does not have this behavior on a 64-bit OS.
Anyways, I've submitted a patch on an existing bug, who knows if it'll take. :)
https://issues.apache.org/bugzilla/show_bug.cgi?id=48476
On Aug 17, 2010, at 4:28 PM, Philip Prindeville wrote:
> Hey Chris,
>
> I'm assuming this is only happening on a 32-bit native machine, right?
>
> Because on an x86_64 machine '%lu' would be 64-bit and behave correctly, yes?
>
> -Philip
>
>
> On 8/11/10 8:51 AM, Chris Knight wrote:
>> I spent half-a-day yesterday trying to figure out why I was crashing in apr_psprintf on a strlen until I realized that my "%llu%s" format string was causing it to use my long long int as a char *.
>>
>> Needless to say, no harm in adding support for %ll[du] yes?
>>
>> Ah, 64-bit fun for everyone....
>>
>> Example code:
>>
>> #include<apr.h>
>> #include<apr_pools.h>
>> #include<apr_strings.h>
>> #include<stdio.h>
>>
>> int main(int argc, char **argv) {
>> apr_pool_t *pool = NULL;
>> char *s = "hello world"; u_int64_t v = 12345678;
>>
>> apr_pool_initialize(); apr_pool_create(&(pool), NULL);
>> printf("%llu%s", v, s); // works
>> char *f = apr_psprintf(pool, "%llu%s", v, s); // segfault on strlen
>> printf("%s\n", f);
>> }
>
Re: %lld/%llu not handled by apr_vformatter
Posted by Philip Prindeville <ph...@redfish-solutions.com>.
Hey Chris,
I'm assuming this is only happening on a 32-bit native machine, right?
Because on an x86_64 machine '%lu' would be 64-bit and behave correctly, yes?
-Philip
On 8/11/10 8:51 AM, Chris Knight wrote:
> I spent half-a-day yesterday trying to figure out why I was crashing in apr_psprintf on a strlen until I realized that my "%llu%s" format string was causing it to use my long long int as a char *.
>
> Needless to say, no harm in adding support for %ll[du] yes?
>
> Ah, 64-bit fun for everyone....
>
> Example code:
>
> #include<apr.h>
> #include<apr_pools.h>
> #include<apr_strings.h>
> #include<stdio.h>
>
> int main(int argc, char **argv) {
> apr_pool_t *pool = NULL;
> char *s = "hello world"; u_int64_t v = 12345678;
>
> apr_pool_initialize(); apr_pool_create(&(pool), NULL);
> printf("%llu%s", v, s); // works
> char *f = apr_psprintf(pool, "%llu%s", v, s); // segfault on strlen
> printf("%s\n", f);
> }