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/%3cb51ffb6f1003100926n22c1dd79id9696972b23a1...@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 > <christopher.d.kni...@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); >> }
