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: Sat, 24 Mar 2012 10:27:12 +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> <4F6CC06C.3090205@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec52d58f73be48c04bbf9c080 X-Trace: dough.gmane.org 1332581262 12724 80.91.229.3 (24 Mar 2012 09:27:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 24 Mar 2012 09:27:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 24 10:27:42 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 1SBNG9-0002eg-J2 for ged-emacs-devel@m.gmane.org; Sat, 24 Mar 2012 10:27:41 +0100 Original-Received: from localhost ([::1]:33354 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBNG8-0006Zm-TP for ged-emacs-devel@m.gmane.org; Sat, 24 Mar 2012 05:27:40 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33906) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBNG6-0006ZS-3c for emacs-devel@gnu.org; Sat, 24 Mar 2012 05:27:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBNG4-0000Ae-DD for emacs-devel@gnu.org; Sat, 24 Mar 2012 05:27:37 -0400 Original-Received: from mail-bk0-f41.google.com ([209.85.214.41]:65036) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBNG4-0000AP-41 for emacs-devel@gnu.org; Sat, 24 Mar 2012 05:27:36 -0400 Original-Received: by bkwq16 with SMTP id q16so3768277bkw.0 for ; Sat, 24 Mar 2012 02:27:33 -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=UbYE9dEXEsg02hczSgEPxlizPTw15+SeUNEuXcBes24=; b=ZwoecUOinXLL2ABJ8/HOnZ5aBziW61wBL6i6Dt0cZgCsdfzV36jpWHiNMJBQD/PQFR +6G0pE/C961EHJ2NnJnUaKVFMx8RlmedtN3GYI6Fw4VrFv+7DHO6bYVQfGhBhd6We0e7 z5faOhCyvv/vqPKewbHdyDJ7MH1XlCvyt/wgkQkABFXwgKS4gfryYv8GhhZ0S8sXO3WR 0OfSYP3DappzkvYnXtfR7dw1hIA/V5VzM+hVTbGWBV6JvIRSbs/wE2irJX9dPjGBp4TN RgyLoNpEPkrUfBtKoxfBQMBwJl7W5dAZt3sntdwck8DnNzr3xEttipXkD1bT0hZsxH/n 3sgg== Original-Received: by 10.204.173.11 with SMTP id n11mr5808771bkz.120.1332581253243; Sat, 24 Mar 2012 02:27:33 -0700 (PDT) Original-Received: by 10.204.179.143 with HTTP; Sat, 24 Mar 2012 02:27:12 -0700 (PDT) In-Reply-To: <4F6CC06C.3090205@cs.ucla.edu> X-Google-Sender-Auth: V_5mT9P9eAz3rjRTyjMzDF-O8V8 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:149203 Archived-At: --bcaec52d58f73be48c04bbf9c080 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > > 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 =3D FOO; > > Again, any compiler that warns about potential overflow of > 2147483647+1 should be ignored, because the expression > 2147483647+1 cannot possibly be evaluated. > Ok. I read the intprops.h file and I agree with this example. Pity there is no other (simpler) way to handle this. Thanks for the explanations. Fabrice --=20 Fabrice Popineau ----------------------------- SUPELEC D=E9partement Informatique 3, rue Joliot Curie 91192 Gif/Yvette Cedex Tel direct : +33 (0) 169851950 Standard : +33 (0) 169851212 ------------------------------ --bcaec52d58f73be48c04bbf9c080 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The situation wit= h the INT_RANGE_OVERFLOW check is similar, except
there the macro is more like this:

=A0#define a 2147483647<= /a>
=A0#define b 1
=A0#define FOO (INT_ADD_OVERFLOW (a,b) ? INT_MAX : (a)+(b))
=A0int i =3D FOO;

Again, any compiler that warns about potential overflow of
2147483647+1 should b= e ignored, because the expression
2147483647+1 cannot p= ossibly be evaluated.

Ok. I read the intprops.h file and I agre= e with this example.=A0
Pity there is no other (simpler) way to handle = this.

Thanks for the explanations.

Fabrice




--=
Fabrice Popineau
-----------------------------
SUPELEC
D=E9partement Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
S= tandard : +33 (0) 169851212
------------------------------
<= div>

--bcaec52d58f73be48c04bbf9c080--