![](https://seccdn.libravatar.org/avatar/835a9492d596a5f4a8eba92c90ac373b.jpg?s=120&d=mm&r=g)
On Wed, 7 May 2014, Marcus Meissner wrote:
On Tue, May 06, 2014 at 08:59:59PM -0400, Cristian Rodríguez wrote:
El 06/05/14 20:28, Jan Engelhardt escribió:
On Wednesday 2014-05-07 01:31, Cristian Rodríguez wrote:
Suppose I have a large body of code, of which programmers are lazy and do something like this:
$ cat lazy.c int printf(const char *format, ...); int main(void) { printf("Problem?"); return 0; }
and the resulting code calls ..call printf .. instead of call __printf_chk .. as it would when <stdio.h> is included.
__printf_chk is called. The presence of a redundant identical function declarations/prototypes does not change the program behavior.
Ok, let me throw in another example ..
#include <stdio.h> char *strcpy(char *dest, const char *src);
int main(void) { char c[3]; strcpy(c, "fuuuuuuuuuuuuuuuuuuuuuuuuuckme"); printf("%s", c); return 0; }
This is valid but obviously buggy on purpose..
with <string.h> included I get the obvious warning..
In function ‘strcpy’, inlined from ‘main’ at c.c:10:5: /usr/include/bits/string3.h:104:3: warning: call to __builtin___memcpy_chk will always overflow destination buffer return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
No <string.h> and the compiler is silent though the program still crashes. this is more in line with the actual concern I have.
If they want to shoot themselves in the foot, it is hard to avoid.
Yep. And as all the fortify stuff is transparent to GCC there is no way GCC can warn about missing fortification. Richard. -- Richard Biener <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer