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