Jeffrey Walton wrote: > On Sat, Dec 15, 2012 at 9:35 PM, Jim Meyering <j...@meyering.net> wrote: >> Paul Eggert wrote: >>> On 12/15/2012 05:54 PM, Jim Meyering wrote: >>>> FYI, a couple of weeks ago, Aki Helin exposed still more problems in >>>> gzip's unpacking code. >>> >>> Well, to be fair, I also have a similar problem with 'tar' >>> in my inbox, from Aki, but I'm not inclined to suggest that >>> we stop using 'tar'.... >> >> Of course. Nor am I. >> GNU tar's overall code quality is far higher than that of gzip. > -Wall -Wextra -Wconversion -Wstrict-overflow go a long way in > uncovering basic developer problems, like truncations, conversions, > and 2's compliment behavior. Everyone - from GNU to private > development teams - could benefit from the illumination of issues by > the toolchain's warning system. > > I understand the warning system produces false positives at times, but > I don't throw the baby out with the bath water. I work around the > warning system's short comings in an effort to keep code quality up. > Its what we have to do to separate the wheat from the chaff. > > Its too bad they are not used more often.
If you have noticed real problems in tar or gzip (or any other GNU project) about which gcc can warn, please let us know. It sounds like you are trying to teach grandma how to suck eggs :-) Did you realize that several GNU projects now enable virtually every gcc warning that is available (even including those that are new in the upcoming gcc-4.8, for folks that use bleeding edge gcc) via gnulib's manywarnings.m4 configure-time tests? Of course, there is a list of warnings that we do disable, due to their typical lack of utility and the invasiveness of changes required do suppress them. _______________________________________________ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
