apr_vformatter mishandles "%n" (patch included)

The call

  apr_psprintf (pool, "%u%n", random_number, &random_portion_width);

was producing a string that had garbage bytes following the correctly
formatted number. Turns out that even for "%n", apr_psprintf() was
printing into the string. The bug was in apr_vformatter().

The patch below is a pretty quick job; if someone else has a more
elegant fix, that's great too.

-Karl

2000-10-30 Karl Fogel <kfogel@collab.net>

        * apr_snprintf.c (apr_vformatter): don't print anything for "%n".

--- apr_snprintf.c Mon Oct 30 14:23:52 2000
+++ apr_snprintf.c Mon Oct 30 14:30:06 2000
@@ -708,6 +708,7 @@
             /*
              * Default variable settings
              */
+ boolean_e print_something = YES;
             adjust = RIGHT;
             alternate_form = print_sign = print_blank = NO;
             pad_char = ' ';
@@ -1000,6 +1001,7 @@
                     *(va_arg(ap, short *)) = cc;
                 else
                     *(va_arg(ap, int *)) = cc;
+ print_something = NO;
                 break;
 
                 /*
@@ -1131,10 +1133,12 @@
             /*
              * Print the string s.
              */
- for (i = s_len; i != 0; i--) {
- INS_CHAR(*s, sp, bep, cc);
- s++;
- }
+ if (print_something == YES) {
+ for (i = s_len; i != 0; i--) {
+ INS_CHAR(*s, sp, bep, cc);
+ s++;
+ }
+ }
 
             if (adjust_width && adjust == LEFT && min_width > s_len)
                 PAD(min_width, s_len, pad_char);
Received on Sat Oct 21 14:36:13 2006