From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Windows 64 port Date: Wed, 29 Feb 2012 11:43:28 -0800 Organization: UCLA Computer Science Department Message-ID: <4F4E7FE0.9040907@cs.ucla.edu> References: <20120219211800.0000558f@unknown> <834numv7js.fsf@gnu.org> <4F428780.8070902@cs.ucla.edu> <4F4D507F.7030008@cs.ucla.edu> <83obshcy8n.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1330544664 331 80.91.229.3 (29 Feb 2012 19:44:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 29 Feb 2012 19:44:24 +0000 (UTC) Cc: fabrice.popineau@supelec.fr, emacs-devel@gnu.org, ajmr@ilovetortilladepatatas.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 29 20:44:23 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1S2pRm-0006I1-92 for ged-emacs-devel@m.gmane.org; Wed, 29 Feb 2012 20:44:22 +0100 Original-Received: from localhost ([::1]:52346 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2pRl-0007O0-Jp for ged-emacs-devel@m.gmane.org; Wed, 29 Feb 2012 14:44:21 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:32978) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2pRi-0007Nu-6D for emacs-devel@gnu.org; Wed, 29 Feb 2012 14:44:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S2pRN-0007ok-SF for emacs-devel@gnu.org; Wed, 29 Feb 2012 14:44:17 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:51745) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2pR1-0007eo-Ik; Wed, 29 Feb 2012 14:43:35 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id B615D39E800B; Wed, 29 Feb 2012 11:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zr95pVjrQAsO; Wed, 29 Feb 2012 11:43:29 -0800 (PST) Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id C744B39E8008; Wed, 29 Feb 2012 11:43:28 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 In-Reply-To: <83obshcy8n.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 131.179.128.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:148841 Archived-At: >> We don't need to modify the mainline Emacs code in order to >> pacify third-party compilers that issue incorrect warnings. > > What is incorrect about that warning? As Fabrice explained, the warning is about code that is never executed on his platform, because it's inside a conditional that is always false, and so the bug cannot possibly occur. The conditional itself is a constant, and decent compiler will optimize away the code in question. The conditional is present precisely to avoid the overflow that the compiler is mistakenly warning about. There is no easy way to rewrite the code that will both pacify the broken compiler and keep the code modular and portable. Cases like these are an an easy call: leave the code alone and ignore the bogus warning. If possible, pass a flag to the compiler telling it not to issue bogus warnings like that. Or get the compiler bug fixed. Whatever. > If some compiler tells us something valuable about the code, we > need not ignore it just because it's "third-party". True, but it appears that many of the fixes in his patch are to pacify warnings like the above. That is, it appears that a class of warnings are often bogus and do not correspond to real bugs. This is an easy call: leave the code alone.