Bug#277667: libc6: printf formats using parameter numbers and floats has internal error

[Steve Greenland <steveg@lsli.com>]

Package: libc6
Version: 2.3.2.ds1-16
Severity: normal

There seems to be a problem when using printf() format specifies that
combine paramenter number specification and floating point values, e.g.
"%1$3.2f".

Consider this code:

#include <stdio.h>

int main(void)
{

    int d= 5;
    int h = 7;
    double x= 3.2;

    printf("   Okay: float: %4.1f, int: %4d\n", x, d);
    printf("   Okay:   int: %1$4d, int: %2$4d\n", h, d);
    printf("Problem: float: %1$4.1f, int: %2$4d\n", x, d);

    return 0;
}


Compiled and run under valgrind, you get this output:

==18169== Memcheck, a memory error detector for x86-linux.
==18169== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==18169== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==18169== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==18169== For more details, rerun with: -v
==18169== 
   Okay: float:  3.2, int:    5
   Okay:   int:    7, int:    5
==18169== Conditional jump or move depends on uninitialised value(s)
==18169==    at 0x1B9641E9: __printf_fp (in /lib/libc-2.3.2.so)
==18169==    by 0x1B961A6B: _IO_vfprintf (in /lib/libc-2.3.2.so)
==18169==    by 0x1B9688D1: _IO_printf (in /lib/libc-2.3.2.so)
==18169==    by 0x8048465: main (in /home/steveg/src/testsyslog)
Problem: float:  3.2, int:    5
==18169== 
==18169== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 11 from 1)
==18169== malloc/free: in use at exit: 0 bytes in 0 blocks.
==18169== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==18169== For a detailed leak analysis,  rerun with: --leak-check=yes
==18169== For counts of detected errors, rerun with: -v


This is almost certainly an upstream problem, as I get identical (well,
different addresses) results on RHEL 3.0, but if I report it to you, I
don't have to fight bugzilla. :-)

I realize this is fairly obscure, but I found this while trying to track
down why a particular program would (very rarely) go into an infinite
loop *after* exit(), deep down in the libc cleanup routines. Presumably
*something* was stomping on internal memory. This might be it. Or not.
In any case, worth fixing eventually, yes?

Steve

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (800, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-1-686
Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to C)

Versions of packages libc6 depends on:
ii  libdb1-compat                 2.1.3-7    The Berkeley database routines [gl

-- no debconf information