From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.devel Subject: Re: Windows 64 port Date: Thu, 22 Mar 2012 18:31:30 +0100 Message-ID: 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: multipart/alternative; boundary=bcaec52d58f78f12fd04bbd848bb X-Trace: dough.gmane.org 1332437536 6210 80.91.229.3 (22 Mar 2012 17:32:16 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Mar 2012 17:32:16 +0000 (UTC) Cc: Eli Zaretskii , ajmr@ilovetortilladepatatas.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 22 18:32:14 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 1SAlrr-0005jX-27 for ged-emacs-devel@m.gmane.org; Thu, 22 Mar 2012 18:32:07 +0100 Original-Received: from localhost ([::1]:36590 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAlrq-00083G-DA for ged-emacs-devel@m.gmane.org; Thu, 22 Mar 2012 13:32:06 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42085) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAlrk-0007rw-3L for emacs-devel@gnu.org; Thu, 22 Mar 2012 13:32:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SAlri-0007uG-7i for emacs-devel@gnu.org; Thu, 22 Mar 2012 13:31:59 -0400 Original-Received: from mail-bk0-f41.google.com ([209.85.214.41]:56652) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAlre-0007si-HN; Thu, 22 Mar 2012 13:31:54 -0400 Original-Received: by bkwq16 with SMTP id q16so2414603bkw.0 for ; Thu, 22 Mar 2012 10:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=uzHvYyGfhAEJQelIwUhe6AWEhYeh03m2oCqoIN/o9oo=; b=yg6dymPT4JCX8M4MMRwEBC0zNGOzNyAI3H8Dpli73lwMSnWKAzJF352vto+AUCxIkQ 7k9dIWog35UZn14zjrqpN8CEqOkkgesomD3uWrJM4ZSEdvMowOyvqPuN04usBOaxhpVJ dTtbblUT2cDSNEodlmfZ5T3n/f5ppi7G3Qs4gl8TAuM2vx2WBFbLqps778Z1S4PL4kSv 8swIwkLfXwEx96CJKb9sZP8s5SeevoHU1HV0EGNpON7VkbuWQJ4er9FYTlV1qPx3MHZq B3YkXGIOzWkNA+QnJFC0yA6G3XTVDnYy7rdYLWGZLjQIJwuUURp8GOtJHwCnx3ugpWWo K4UA== Original-Received: by 10.204.173.11 with SMTP id n11mr3407271bkz.120.1332437511508; Thu, 22 Mar 2012 10:31:51 -0700 (PDT) Original-Received: by 10.204.179.143 with HTTP; Thu, 22 Mar 2012 10:31:30 -0700 (PDT) In-Reply-To: <4F4E7FE0.9040907@cs.ucla.edu> X-Google-Sender-Auth: 6Wds0bGh51CtzImMEVcvKC7qLbY X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.214.41 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:149174 Archived-At: --bcaec52d58f78f12fd04bbd848bb Content-Type: text/plain; charset=ISO-8859-1 About this code / suggested patch : > In src/dispnew.c:6402, height and width should probably be unsigned. The > checking by > INT_ADD_RANGE_OVERFLOW results in a compiler warning about integral > constant overflow > because it tries to compute (INTMIN - 2) which obviously is out of range. > The value is not used in this case, but the compiler may emit the warning > anyway. You wrote : We don't need to modify the mainline Emacs code in order to pacify third-party compilers that issue incorrect warnings. We can safely ignore these warnings and leave the code alone. And next : 2012/2/29 Paul Eggert > >> 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. 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. -- Fabrice --bcaec52d58f78f12fd04bbd848bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable About this code / suggested patch :


= > In src/dispnew.c:6402, height and width should probably be unsigned. T= he
> checking by
> INT_ADD_RANGE_OVERFLOW results= in a compiler warning about integral
> constant overflow
> because it tries to compute (INT= MIN - 2) which obviously is out of range.
> The value is not u= sed in this case, but the compiler may emit the warning
> anyw= ay.

You wrote :

We don't need = to modify the mainline Emacs code in order to
pacify third-party = compilers that issue incorrect warnings.
We can safely ignore the= se warnings and leave the code alone.

And next :

2012/2/2= 9 Paul Eggert <e= ggert@cs.ucla.edu>
>> We don't need to modify the mainline Emacs c= ode 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 execute= d
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. =A0The conditional is present
precisely to avoid the overflow that the compiler is mistakenly warning
about. =A0There 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. =A0If possible, pass a flag to the compiler
telling it not to issue bogus warnings like that. =A0Or get the
compiler bug fixed. =A0Whatever.

The constant is gene= rated by the preprocessor.=A0
So it is not a compiler bug but a g= ood catch from the compiler.
Luckily, the code is not executed. G= iven the rather deep stack
of macros, if it were executed without any warning, it would be
<= div>difficult to catch by hand.

--
Fabrice
=
--bcaec52d58f78f12fd04bbd848bb--