From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#8545: issues with recent doprnt-related changes Date: Sat, 30 Apr 2011 22:41:38 -0700 Organization: UCLA Computer Science Department Message-ID: <4DBCF292.4030002@cs.ucla.edu> References: <4DB50AB9.6060100@cs.ucla.edu> <83tydmaeo3.fsf@gnu.org> <4DB65FF1.5010003@cs.ucla.edu> <83aafb8p4a.fsf@gnu.org> <4DB8ABEA.3080503@cs.ucla.edu> <4DB8DAF8.7070408@cs.ucla.edu> <4DBB4E80.2020102@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1304230022 18039 80.91.229.12 (1 May 2011 06:07:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 1 May 2011 06:07:02 +0000 (UTC) Cc: lekktu@gmail.com, 8545@debbugs.gnu.org To: rms@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 01 08:06:57 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QGPo0-0001Rw-Kw for geb-bug-gnu-emacs@m.gmane.org; Sun, 01 May 2011 08:06:56 +0200 Original-Received: from localhost ([::1]:38134 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QGPnz-0004md-N0 for geb-bug-gnu-emacs@m.gmane.org; Sun, 01 May 2011 02:06:55 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:60522) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QGPnx-0004mT-OR for bug-gnu-emacs@gnu.org; Sun, 01 May 2011 02:06:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QGPnw-00008D-7t for bug-gnu-emacs@gnu.org; Sun, 01 May 2011 02:06:53 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QGPnw-00007y-6B for bug-gnu-emacs@gnu.org; Sun, 01 May 2011 02:06:52 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QGPPu-0007MD-H4; Sun, 01 May 2011 01:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 May 2011 05:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8545-submit@debbugs.gnu.org id=B8545.130422850728259 (code B ref 8545); Sun, 01 May 2011 05:42:02 +0000 Original-Received: (at 8545) by debbugs.gnu.org; 1 May 2011 05:41:47 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QGPPf-0007Lk-Hy for submit@debbugs.gnu.org; Sun, 01 May 2011 01:41:47 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QGPPd-0007LY-Dn for 8545@debbugs.gnu.org; Sun, 01 May 2011 01:41:46 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id E07A339E80F8; Sat, 30 Apr 2011 22:41:39 -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 SEJ7uugXUZMp; Sat, 30 Apr 2011 22:41:39 -0700 (PDT) Original-Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 5EDBA39E80F2; Sat, 30 Apr 2011 22:41:39 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 01 May 2011 01:42:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:46121 Archived-At: On 04/30/11 14:03, Richard Stallman wrote: > long > foo (char *p, int i) > { > return &p[i + 1] - &p[i]; > } > ... > i+1 is computed as an integer, but then it gets converted to a long. Unfortunately that doesn't explain FOO's behavior. If i+1 is computed as an int and if wraparound is required, then when i is INT_MAX, i+1 must be INT_MIN. (FOO does not convert i+1 to long; but even if it did, INT_MIN's value would be unchanged by that conversion.) If p is pointing into a large array, &p[INT_MIN] and &p[INT_MAX] can both be valid addresses, and in that case foo (p, INT_MAX) would have to yield -2**32 + 1 on a typical 64-bit host where signed integer arithmetic wrapped around. But in my experience no compiler does it that way. FOO always returns 1. > What happens here seems to be an issue about type conversion combined > with addition -- not addition itself. I'm afraid not. First, FOO doesn't have any type conversions. If I is an int, A[I] doesn't convert I to any other type; it simply uses I's value without conversion. Second, it's easy to construct an example that involves only "int": int bar (int i) { return i < i + 1; } With many compilers, BAR always returns 1, even when i == INT_MAX. > These compilers are taking a strange liberty. > Why isn't that a bug? Well, for starters, most programmers *expect* FOO to return 1, and similarly for BAR. Why would a programmer file a bug report when the program is behaving as expected? > printf ("%d", INT_MAX+1); > will output INT_MIN. That's true for all systems I have ready access to, yes. And I expect there are other cases where int arithmetic wraps around reliably. But there are many practical cases where it doesn't. We cannot simply advise programmers to assume that adding 1 to INT_MAX always results in INT_MIN, as that assumption is often incorrect nowadays.