Please do not enforce -D_FORTIFY_SOURCE=2 this on the default compiler options as is currently done with gcc 4.3.4 in desktop profile. By all means add it to hardened profiles, or have ebuild set it when it builds packages, but when I fire up gcc myself I expect to be able to compile valid C code. I can no longer find any normative documentation on -D_FORTIFY_SOURCE, but I vaguely recall that -D_FORTIFY_SOURCE=1 was less aggressive and didn't violate the C standard. Reproducible: Always Steps to Reproduce: 1. Install gcc (see below for version) 2. Compile the program below with "gcc -o writable writable.c -Wall -g -O2 -std=c89" (also occurs without -std=c89, just wanted to illustrate the point that I'm asking for C89 compliance and not getting it). #include <stdio.h> int main() { char form[10] = "test %n\n"; int out; printf(form, &out); return 0; } 3. Run it. Actual Results: *** %n in writable segment detected *** test Aborted Expected Results: test Profile: /etc/make.profile -> ../usr/portage/profiles/default/linux/amd64/10.0/desktop gcc version: sys-devel/gcc-4.3.4: Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.4/work/gcc-4.3.4/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.4 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.4 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.4/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.4/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --disable-libgcj --enable-languages=c,c++,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.4 p1.0, pie-10.1.5' Thread model: posix gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5)
> Actual Results: > *** %n in writable segment detected *** > test Aborted Same here on amd64.
Just a guess, but might be bug 289743 related to this?
> Just a guess, but might be bug 289743 related to this? Don't think so, exactly... it might be triggered by the -D_FORTIFY_SOURCE=2, but based on the error message there is looks like there really is a bug in the application. This bug is unrelated to the use of GCC for compiling packages, I just don't want the GCC ebuild to take away C compliance.
I found the text I remembered seeing, from http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html: " The intended use in glibc is that by default no protection is done, when the above GCC 4.0+ and -D_FORTIFY_SOURCE=1 is used at optimization level 1 and above, security measures that shouldn't change behaviour of conforming programs are taken. With -D_FORTIFY_SOURCE=2 some more checking is added, but some conforming programs might fail. " So -D_FORTIFY_SOURCE=1 ought to be sane.
while i understand your concern, the benefits outweigh the inconvenience of a minority. it's trivial to either fix your code or disable fortify. -U_FORTIFY_SOURCE or set it lower yourself with -D_FORTIFY_SOURCE=1 and technically speaking, gcc *did* compile your valid code just fine. the error thrown at *runtime* came from glibc.
> while i understand your concern, the benefits outweigh the inconvenience of a > minority. it's trivial to either fix your code or disable fortify. Is there an easy system-wide fix for the minority? i.e. Is there some environment variable I can set or file I can edit (that won't get overwritten next time I merge gcc) to restore the upstream behaviour (whether in the compiler or in glibc)? Failing that, any chance of a USE flag (such as a yes-im-an-idiot-but-i-want-to-disable-fortify-anyway flag) to disable this patch?
i just told you how -- use -U_FORTIFY_SOURCE, so you can just add that to your make.conf:CPPFLAGS if you mean outside of portage and just random command line apps, you can always reverse the 1 line change to gcc/gcc.c from 10_all_gcc-default-fortify-source.patch and stick that into your site-specific patches dir: /etc/portage/patches/sys-devel/gcc/ that should get applied automatically when emerging gcc. i'm not going to add a USE flag for this since the minority can do the above wrt custom patching.
Thanks, I wasn't aware of the site-specific patching facility, and it looks like it should solve my problem.
