Re: BUG: printf formatting libc.so.6

Re: BUG: printf formatting libc.so.6

[Bruce Korb]

Petr Vandrovec wrote:
> > Andreas Schwab wrote:
> > > |> > |> /* This program fails */
> > > |> >
> > > |> > No, it doesn't.
> > > |>
> > > |> Yes, it does:
> > >
> > > Works for me.
> >
> > Then it must be a bug fixed since SuSE 8.2 was cut.
> > I certainly do not update libc frequently.  I do
> > it with installations only.  So, more specifically,
> > does it work for you on a vanilla SuSE 8.2?   If so,
> > then what conceivable environmental issue might cause
> > the problem?  Thank you. - Bruce
> 
> Do not worry... I tried latest Debian unstable (glibc 2.3.1-17)
> and RedHat (glibc 2.3.2-41), and neither works (and actually
> RH's 2.3.2's output is worse than debian's 2.3.1).
> 
> Simplified
> 
> #include <stdio.h>
> void main(void) { printf("%1$d %1$c %2$d %2$c\n", 32, 49); }
> 
> yields "32   1074178865 1" on Debian, while "1345134440   -1073746895 1"
> on RedHat...
> 
> In all cases low byte of %d is correct, but upper 3 bytes are corrupted
> by some garbage.
> 
> Both RH's and Debian's glibcs were compiled by gcc-3.2.3. Maybe this is
> a culprit? Observed behavior looks like some strange pointer aliasing
> issue to me.

*sigh*.  GCC may be 100% correct in terms of language law on how
to interpret aliasing, but if it causes problems in software as
fundamental as the kernel and libc perhaps the correctness comes
at too high a price.  What are the results with a glibc compiled
with the same compiler but with aliasing optimizations disabled?
(not having a ready development environment for downloading and
testing glibc myself.)

For the benefit of the GCC list:

$ gcc -o broken broken.c && ./broken ; echo $?
ch1: 49 ('1') -- ch2: -1073748704 (' ')
1
$ rcp broken.c ellen:tmp/.
/home/bkorb/tools/mine/lib/textmmap
$ rsh ellen
Last login: Mon May 26 09:40:05 from 172.22.12.211
Sun Microsystems Inc.   SunOS 5.8       Generic February 2000
You have mail.
$ cd tmp
$ cc -o working broken.c && ./working ; echo $?
ch1: 49 ('1') -- ch2: 32 (' ')
0
$ gcc -o working broken.c && ./working ; echo $?
ch1: 49 ('1') -- ch2: 32 (' ')
0
$ exit
$ rcp broken.c vcslnx9:tmp/.
/home/bkorb/tools/mine/lib/textmmap
$ rsh vcslnx9
Last login: Wed May 14 07:25:57 from ellen.veritas.com
$ cd tmp
$ cc -o broken broken.c && ./broken ; echo $?
ch1: 4145 ('1') -- ch2: 1053975328 (' ')
1
$ uname -a
Linux vcslnx9 2.4.9-13smp #1 SMP Tue Oct 30 19:57:16 EST 2001 i686 unknown
$ cat broken.c
#include <stdio.h>

static const char zSamp[] =
"ch1: 49 ('1') -- ch2: 32 (' ')\n";
static const char zFmt[] =
"ch1: %1$d ('%1$c') -- ch2: %2$d ('%2$c')\n";

static char zBuff[ 128 ];

int
main( int argc, char** argv )
{
    sprintf( zBuff, zFmt, 0x31, 32 );
    fputs( zBuff, stdout );
    return strcmp( zBuff, zSamp ) != 0;
}

Re: BUG: printf formatting libc.so.6

[Jakub Jelinek]

On Mon, May 26, 2003 at 12:11:19PM -0700, Bruce Korb wrote:
> > Simplified
> > 
> > #include <stdio.h>
> > void main(void) { printf("%1$d %1$c %2$d %2$c\n", 32, 49); }
> > 
> > yields "32   1074178865 1" on Debian, while "1345134440   -1073746895 1"
> > on RedHat...

Reproduced, looking into it.

	Jakub

Re: BUG: printf formatting libc.so.6

[Segher Boessenkool]

>>void main(void) { printf("%1$d %1$c %2$d %2$c\n", 32, 49); }

This fails on ancient glibc's, with ancient gcc's, too.
The failure mode is more apparent on big-endian systems.

See  union printf_arg  and how it's used in vfprintf.c .

The fix is probably to document not to use a positional
parameter more than once.


Segher