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: Fri, 23 Mar 2012 11:26:52 -0700 Organization: UCLA Computer Science Department Message-ID: <4F6CC06C.3090205@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> <4F4E7FE0.9040907@cs.ucla.edu> 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 1332527228 10932 80.91.229.3 (23 Mar 2012 18:27:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 23 Mar 2012 18:27:08 +0000 (UTC) Cc: emacs-devel@gnu.org To: Fabrice Popineau Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 23 19:27:06 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 1SB9CY-0002aS-Eu for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2012 19:27:02 +0100 Original-Received: from localhost ([::1]:39200 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SB9CX-00021D-RT for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2012 14:27:01 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34122) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SB9CU-0001zj-Mn for emacs-devel@gnu.org; Fri, 23 Mar 2012 14:26:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SB9CS-0002eO-TD for emacs-devel@gnu.org; Fri, 23 Mar 2012 14:26:58 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:34743) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SB9CS-0002dQ-Kv for emacs-devel@gnu.org; Fri, 23 Mar 2012 14:26:56 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 71E9039E800C; Fri, 23 Mar 2012 11:26:53 -0700 (PDT) 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 hcqq7A9xJZts; Fri, 23 Mar 2012 11:26:53 -0700 (PDT) Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 0BCB539E8008; Fri, 23 Mar 2012 11:26:53 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 In-Reply-To: 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:149200 Archived-At: On 03/22/2012 10:31 AM, Fabrice Popineau wrote: > The constant is generated by the preprocessor. > So it is not a compiler bug but a good catch from the compiler. > Luckily, the code is not executed. Given the rather deep stack > of macros, if it were executed without any warning, it would be > difficult to catch by hand. The code cannot possibly be executed, so it's not a good catch by the compiler. Here's a simpler example: #define Z 0 #define FOO (Z == 0 ? INT_MAX : 1000 / Z) int i = FOO; Here, the compiler should not complain about division by zero, even though the constant is generated by the preprocessor, because FOO's body is designed to divide by Z only when Z is nonzero, and the expression 1000 / Z cannot possibly be executed when Z is zero. Of course compilers are free to generate warnings whenever they like, and some will indeed warn about this example if you enable the right flags, but this warning is harmful and not helpful: it should be ignored and the code should not be changed and you're better off simply disabling the compiler warning. The situation with the INT_RANGE_OVERFLOW check is similar, except there the macro is more like this: #define a 2147483647 #define b 1 #define FOO (INT_ADD_OVERFLOW (a,b) ? INT_MAX : (a)+(b)) int i = FOO; Again, any compiler that warns about potential overflow of 2147483647+1 should be ignored, because the expression 2147483647+1 cannot possibly be evaluated.