From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1M0TiA-0000Bm-KH for mharc-grub-devel@gnu.org; Sun, 03 May 2009 00:53:58 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M0Ti8-0000BF-Qw for grub-devel@gnu.org; Sun, 03 May 2009 00:53:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M0Ti3-0000B1-8X for grub-devel@gnu.org; Sun, 03 May 2009 00:53:55 -0400 Received: from [199.232.76.173] (port=42697 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M0Ti3-0000Ay-5Y for grub-devel@gnu.org; Sun, 03 May 2009 00:53:51 -0400 Received: from c60.cesmail.net ([216.154.195.49]:37487) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1M0Ti2-000111-Q7 for grub-devel@gnu.org; Sun, 03 May 2009 00:53:50 -0400 Received: from unknown (HELO smtprelay2.cesmail.net) ([192.168.1.112]) by c60.cesmail.net with ESMTP; 03 May 2009 00:53:50 -0400 Received: from [192.168.1.104] (c-69-141-194-35.hsd1.pa.comcast.net [69.141.194.35]) by smtprelay2.cesmail.net (Postfix) with ESMTPSA id C4F8634C6D for ; Sun, 3 May 2009 00:52:25 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: <20090502114155.GE28362@thorin> References: <1239833453.8204.18.camel@mj> <20090502114155.GE28362@thorin> Content-Type: text/plain Date: Sun, 03 May 2009 00:53:49 -0400 Message-Id: <1241326429.8745.45.camel@ct> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: Code quality X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 04:53:57 -0000 On Sat, 2009-05-02 at 13:41 +0200, Robert Millan wrote: > Can we start using -Werror ? If we can't do it globally, at least for > individual modules. This way we gradually prevent regressions in more > areas, and (hopefully) at some point get rid of them. We should fix the warnings first. We have some warnings where we cast a 64-bit address to a 32-bit address without doing any validation. Turning those warnings into errors increases the risk that somebody will add casts mindlessly instead of adding sanity checks. Also, gcc 4.4.0 adds a bunch of warnings about aliasing. It would be better to make the build less verbose by default to make the warnings more visible. -- Regards, Pavel Roskin