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:
perl -ne 'print if 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.
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 web.mit. edu/andersk/ Public/ sprintf- test.c>:
<http://
#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: s*\(\s* ([^,]*) \s*,\s* "%s[^"] *"\s*,\ s*\1\s* ,/'
perl -ne 'print if m/sprintf\
To determine how common the pattern is, I wrote a script to track down instances using Google Code Search, and found 2888 matches: web.mit. edu/andersk/ Public/ sprintf- results> web.mit. edu/andersk/ Public/ sprintf- codesearch. py>.)
<http://
(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://
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.