Consider this piece of code: #include <stdio.h> int main( int argc, char *argv[] ) { char c='v'; int w; w = printf( "%c", c ); printf( "wrote %i bytes\n", w ); w = printf( "%cX", c ); printf( "wrote %i bytes\n", w ); return 0; } From my (admittedly small) knowledge of C, I'd expect this to print: vwrote 1 bytes vXwrote 2 bytes It does, for example on Debian, with glibc 2.3.5. On Gentoo however, I get: vwrote 118 bytes vXwrote 2 bytes Now *this* is weird. But seeing that the ASCII value of "v" is 118 makes wonder if this is somehow putc() related (a putc("v") would return 118). Removing all multi-char printf()s and using objdump, we get something interesting: $ objdump -t a,out|grep -E '(printf|putc)' 00000000 F *UND* 000000c1 putchar@@GLIBC_2.0 $ So seemingly gcc or glibc "magic" replace single-char printf()s with putc() and break the return value. I think this should be fixed, no matter how obscure it may seem or how much of a corner-case it is. Note: I have seen this on three different Gentoo machines (all with glibc 2.3.5-r1) being broken and on several Debian and OS X machines with various glibcs being as expected. Note2: I think one could come up with a scenario where a piece of code relying on printf()s retval may break in a way that's overflowable, but that's probably esoteric.
you neglected to post `emerge info` like the bug report page told you to
*** This bug has been marked as a duplicate of 100172 ***
