So I'd like to bring this back up and reiterate the issue: there is no benefit to the early truncation, and it actively breaks lots of existing software (which is why Debian and Ubuntu have had this fix for 10 years now).
What is the _benefit_ of early truncation that justifies breaking so many existing cases? Can glibc please take this patch? http://paste.ubuntu.com/p/CbrxmSfKD4/ -- You received this bug notification because you are a member of Ubuntu Studio Bugs, which is subscribed to audacious-plugins in Ubuntu. Matching subscriptions: Ubuntu Studio Bugs, ubuntustudio-bugs: blender https://bugs.launchpad.net/bugs/305901 Title: Intrepid gcc -O2 breaks string appending with sprintf(), due to fortify source patch Status in GLibC: Confirmed Status in 4g8 package in Ubuntu: Invalid Status in abiword package in Ubuntu: Invalid Status in asterisk package in Ubuntu: Invalid Status in atomicparsley package in Ubuntu: Invalid Status in audacious-plugins package in Ubuntu: Invalid Status in barnowl package in Ubuntu: Invalid Status in billard-gl package in Ubuntu: Invalid Status in binutils package in Ubuntu: Invalid Status in blender package in Ubuntu: Invalid Status in ctn package in Ubuntu: Invalid Status in gcc-4.3 package in Ubuntu: Invalid Status in glibc package in Ubuntu: Fix Released Status in hypermail package in Ubuntu: Invalid Status in mpeg4ip package in Ubuntu: Invalid Status in nagios-plugins package in Ubuntu: Invalid Status in owl package in Ubuntu: Invalid Status in xmcd package in Ubuntu: Invalid Status in 4g8 source package in Intrepid: Invalid Status in abiword source package in Intrepid: Invalid Status in asterisk source package in Intrepid: Invalid Status in atomicparsley source package in Intrepid: Invalid Status in audacious-plugins source package in Intrepid: Invalid Status in barnowl source package in Intrepid: Invalid Status in billard-gl source package in Intrepid: Invalid Status in binutils source package in Intrepid: Invalid Status in blender source package in Intrepid: Invalid Status in ctn source package in Intrepid: Invalid Status in gcc-4.3 source package in Intrepid: Invalid Status in glibc source package in Intrepid: Fix Released Status in hypermail source package in Intrepid: Invalid Status in mpeg4ip source package in Intrepid: Invalid Status in nagios-plugins source package in Intrepid: Invalid Status in owl source package in Intrepid: Invalid Status in xmcd source package in Intrepid: Invalid Status in 4g8 source package in Jaunty: Invalid Status in abiword source package in Jaunty: Invalid Status in asterisk source package in Jaunty: Invalid Status in atomicparsley source package in Jaunty: Invalid Status in audacious-plugins source package in Jaunty: Invalid Status in barnowl source package in Jaunty: Invalid Status in billard-gl source package in Jaunty: Invalid Status in binutils source package in Jaunty: Invalid Status in blender source package in Jaunty: Invalid Status in ctn source package in Jaunty: Invalid Status in gcc-4.3 source package in Jaunty: Invalid Status in glibc source package in Jaunty: Fix Released Status in hypermail source package in Jaunty: Invalid Status in mpeg4ip source package in Jaunty: Invalid Status in nagios-plugins source package in Jaunty: Invalid Status in owl source package in Jaunty: Invalid Status in xmcd source package in Jaunty: Invalid Bug description: Binary package hint: gcc-4.3 In Hardy and previous releases, one could use statements such as sprintf(buf, "%s %s%d", buf, foo, bar); to append formatted text to a buffer buf. Intrepid’s gcc-4.3, which has fortify source turned on by default when compiling with -O2, breaks this pattern. This introduced mysterious bugs into an application I was compiling (the BarnOwl IM client). Test case: gcc -O2 sprintf-test.c -o sprintf-test <http://web.mit.edu/andersk/Public/sprintf-test.c>: #include <stdio.h> char buf[80] = "not "; int main() { sprintf(buf, "%sfail", buf); puts(buf); return 0; } This outputs "not fail" in Hardy, and "fail" in Intrepid. The assembly output shows that the bug has been introduced by replacing the sprintf(buf, "%sfail", buf) call with __sprintf_chk(buf, 1, 80, "%sfail", buf). A workaround is to disable fortify source (gcc -U_FORTIFY_SOURCE). One might argue that this usage of sprintf() is questionable. I had been under the impression that it is valid, and found many web pages that agree with me, though I was not able to find an authoritative statement either way citing the C specification. I decided to investigate how common this pattern is in real source code. You can search a source file for instances of it with this regex: pcregrep -M 'sprintf\s*\(\s*([^,]*)\s*,\s*"%s[^"]*"\s*,\s*\1\s*,' To determine how common the pattern is, I wrote a script to track down instances using Google Code Search, and found 2888 matches: <http://web.mit.edu/andersk/Public/sprintf-results> (For the curious: the script uses a variant of the regex above. I had to use a binary search to emulate backreferences, which aren’t supported by Code Search, so the script makes 46188 queries and takes a rather long time to run. The source is available at <http://web.mit.edu/andersk/Public/sprintf-codesearch.py>.) My conclusion is that, whether or not this pattern is technically allowed by the C specification, it is common enough that the compiler should be fixed, if that is at all possible. To manage notifications about this bug go to: https://bugs.launchpad.net/glibc/+bug/305901/+subscriptions -- Mailing list: https://launchpad.net/~ubuntustudio-bugs Post to : ubuntustudio-bugs@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntustudio-bugs More help : https://help.launchpad.net/ListHelp