Hi all, since the last time I asked Zac about this it came back to bite me[1] this time I'm going to send the announce to the list first, and if nobody can actually come up with a good reason not to, I'm going to ask Zac tomorrow to re-enable the feature.
What is this about? Portage already reports some of the overflow warnings coming from the glibc fortified sources (-D_FORTIFY_SOURCE=2 -O2 — enabled since gcc 4.3.3-r1 and even stronger with gcc 4.5 and glibc 2.12+, afaict), but they really are divided into two categories: - might overflow (depends on combination of parameters and variables the compiler can't completely untangle); - _will_ overflow (whenever that code path is hit, an overflow will happen). The former we should highlight but not die upon; the latter, though... As Mike and me expressed on the linked bug, code that is built with that warning is code that is going to crash as surely as char *foo = NULL; foo[3] = 'a'; which could result in nasty surprises for users (see [2] for the whole reasoning). Now, we've not seen "proper" false positives (in the Portage sense I mean — because even if the C library hits a false positive, it _will_ crash with an abort() from its own code!), but Kumba pointed me at a case that wasn't entirely clear, and took a bit of detective work to track down [3] so you could have users report issues you cannot easily identify or reproduce. I cannot make promises, but if all else fail I'll see to be around to help you with those cases. So if you want to have your say, gentoo-qa is there for that. Thank you, [1] https://bugs.gentoo.org/show_bug.cgi?id=337031 [2] http://blog.flameeyes.eu/2010/09/14/not-all-failures-are-caused-equal [3] http://blog.flameeyes.eu/2010/09/12/some-_fortify_source-far-fetched-warnings-are-funny -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
