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: Fri, 23 Mar 2012 00:06:20 +0100 Message-ID: References: <20120219211800.0000558f@unknown> <834numv7js.fsf@gnu.org> <4F428780.8070902@cs.ucla.edu> <4F4D507F.7030008@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=000e0ce004b4ff9f8d04bbdcf519 X-Trace: dough.gmane.org 1332457618 3859 80.91.229.3 (22 Mar 2012 23:06:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Mar 2012 23:06:58 +0000 (UTC) Cc: Eli Zaretskii , Paul Eggert , emacs-devel@gnu.org, AJMR To: Andreas Schwab Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 23 00:06:57 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 1SAr5r-00070b-3F for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2012 00:06:55 +0100 Original-Received: from localhost ([::1]:44338 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAr5q-0002I7-31 for ged-emacs-devel@m.gmane.org; Thu, 22 Mar 2012 19:06:54 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:35745) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAr5m-0002H3-GM for emacs-devel@gnu.org; Thu, 22 Mar 2012 19:06:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SAr5k-0004C2-M4 for emacs-devel@gnu.org; Thu, 22 Mar 2012 19:06:50 -0400 Original-Received: from mail-bk0-f41.google.com ([209.85.214.41]:61707) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAr5g-00049x-3t; Thu, 22 Mar 2012 19:06:44 -0400 Original-Received: by bkwq16 with SMTP id q16so2666290bkw.0 for ; Thu, 22 Mar 2012 16:06:41 -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=xe9k+sf8o+Xk9pOJxALkoR6NdM5s/7tC/tGq2Td/3yA=; b=FwvxR0aBzaRENrj563l3oEwbz3Tp9fAJ/C/imtcJLchxnGbn9ERFMydU6uaqTTTBx1 OzzUxApjeEC7EV2f2ixF8D8zIDn20Z8jknJphphKMOOXcmHBQL/sRZFIlyeIHybbXXVM wDm6zktw/qbBjSRMWu2I+gHjJr4eO5JzOtHBjFzhPEj7uPxLKsR177kkdPwB5T5l7ClF tK+RPLexggmCOk0v1ckCeHo1MTRTKX7+oQWQ7Wd8oZs/y4Uh8Vn1sTxx696Ks1ctXt3B uZvzN5BO1hlzkFbl/fufR3lDspx9bnGEYfrVBsj1HL1oZX0wSHCICJSiVIClyvp/kRWC BrGg== Original-Received: by 10.205.122.144 with SMTP id gg16mr3943666bkc.12.1332457601212; Thu, 22 Mar 2012 16:06:41 -0700 (PDT) Original-Received: by 10.204.179.143 with HTTP; Thu, 22 Mar 2012 16:06:20 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: KuYDmOzQfH8JE6rTtIMYHb8orb8 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:149185 Archived-At: --000e0ce004b4ff9f8d04bbdcf519 Content-Type: text/plain; charset=ISO-8859-1 2012/3/22 Andreas Schwab > Fabrice Popineau writes: > > > You mean you can't negate a signed int ? > > Yes, it can overflow. > > Well ... the range is not wider with an unsigned int. Maybe I'm too naive but if x is unsigned, I don't expect to see -x . The implicit semantics for unsigned is x >= 0. Sorry to be so stubborn, but I hate those sign extensions that can arise anywhere. My point is that even if the effect is intended by using unsigned this way, if the same variable is upgraded to long, the sign extension will occur, probably unintented, and not flagged harder by the compiler. -- Fabrice --000e0ce004b4ff9f8d04bbdcf519 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/22 Andreas Schwab <schwab@linux-m68k.org&g= t;
Fabrice Popineau <fabrice.popineau@supelec.fr> writes:

> You mean you can't negate a signed int ?

Yes, it can overflow.

<= br>
Well ... the range is not wider with an unsigned int.
Maybe I'm too naive but if x is unsigned, I don't expect to=A0
see -x . The implicit semantics for unsigned is x >=3D 0.
=A0
Sorry to be so stubborn, but I hate those sign extensions th= at can arise
anywhere. My point is that even if the effect is int= ended by using unsigned
this way, if the same variable is upgraded to long, the sign extension= will
occur, probably unintented, and not flagged harder by the c= ompiler.

--
Fabrice
--000e0ce004b4ff9f8d04bbdcf519--