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: ptrdiff_t misuse Date: Sat, 07 Jul 2012 08:34:00 -0700 Organization: UCLA Computer Science Department Message-ID: <4FF856E8.3060006@cs.ucla.edu> References: <83lij66yq9.fsf@gnu.org> <4FEDB953.1010800@yandex.ru> <4FEEA720.2040405@cs.ucla.edu> <4FEEFBAB.6000404@cs.ucla.edu> <4FF3E1D6.1050103@cs.ucla.edu> <83bojv4h13.fsf@gnu.org> <4FF48920.501@cs.ucla.edu> <83vci22mr0.fsf@gnu.org> <83obnu2e8s.fsf@gnu.org> <4FF62C92.8090406@cs.ucla.edu> <83liix2xvp.fsf@gnu.org> <4FF69476.2070701@cs.ucla.edu> <83k3yh2spu.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1341675260 23978 80.91.229.3 (7 Jul 2012 15:34:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 7 Jul 2012 15:34:20 +0000 (UTC) Cc: Samuel Bronson , dmantipov@yandex.ru, Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 07 17:34:19 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 1SnX1W-0007w1-2y for ged-emacs-devel@m.gmane.org; Sat, 07 Jul 2012 17:34:18 +0200 Original-Received: from localhost ([::1]:38330 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SnX1V-0001h2-0G for ged-emacs-devel@m.gmane.org; Sat, 07 Jul 2012 11:34:17 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54460) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SnX1S-0001gw-2M for emacs-devel@gnu.org; Sat, 07 Jul 2012 11:34:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SnX1Q-0001S7-Gy for emacs-devel@gnu.org; Sat, 07 Jul 2012 11:34:13 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:46072) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SnX1N-0001Qz-G6; Sat, 07 Jul 2012 11:34:09 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 95DDCA6001F; Sat, 7 Jul 2012 08:34:05 -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 KQhSOD7oRCiz; Sat, 7 Jul 2012 08:34:05 -0700 (PDT) Original-Received: from [192.168.1.4] (pool-108-23-119-2.lsanca.fios.verizon.net [108.23.119.2]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id E45D5A60001; Sat, 7 Jul 2012 08:34:04 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.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:151481 Archived-At: On 07/07/2012 03:59 AM, Stefan Monnier wrote: > In the context of Emacs I'm not scared of undefined behavior. Emacs uses undefined behavior all the time, and there's nothing wrong with that. But it has to be careful about which undefined behavior it can rely on. In the old days, it was fine for Emacs to assume that signed integer overflow wraps around. But because compilers have gotten much fancier at optimizing, the corresponding undefined behavior no longer results in simple wraparound, but can lead to subtle logic bugs far away from the offending code. Over the past couple of years we've changed Emacs so that it is now fairly good at avoiding signed integer overflow. One can build it with gcc -ftrapv and it doesn't trap, for example. This kind of analysis and testing helps to make Emacs more reliable. When it doesn't significantly impede more-important concerns it should be encouraged, even if it isn't the highest-priority task.