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 [was :Re: (empty)] Date: Sat, 30 Jun 2012 08:14:19 -0500 Message-ID: <4FEEFBAB.6000404@cs.ucla.edu> References: <83lij66yq9.fsf@gnu.org> <4FEDB953.1010800@yandex.ru> <4FEEA720.2040405@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1341062070 2006 80.91.229.3 (30 Jun 2012 13:14:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 30 Jun 2012 13:14:30 +0000 (UTC) Cc: Dmitry Antipov , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 30 15:14:29 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 1SkxVL-0001nK-Nr for ged-emacs-devel@m.gmane.org; Sat, 30 Jun 2012 15:14:27 +0200 Original-Received: from localhost ([::1]:40817 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SkxVL-0006lp-K1 for ged-emacs-devel@m.gmane.org; Sat, 30 Jun 2012 09:14:27 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56711) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SkxVJ-0006kb-4t for emacs-devel@gnu.org; Sat, 30 Jun 2012 09:14:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SkxVH-0007Pm-AD for emacs-devel@gnu.org; Sat, 30 Jun 2012 09:14:24 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:59050) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SkxVH-0007PX-1k for emacs-devel@gnu.org; Sat, 30 Jun 2012 09:14:23 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 9B14AA6000E; Sat, 30 Jun 2012 06:14:21 -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 9Src3kM+J99I; Sat, 30 Jun 2012 06:14:21 -0700 (PDT) Original-Received: from [192.168.1.16] (unknown [68.171.84.68]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 99B15A60004; Sat, 30 Jun 2012 06:14:20 -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:151322 Archived-At: On 06/30/2012 07:07 AM, Stefan Monnier wrote: > But "fixing" the code like you have will just make it run "correctly" > and so super-extra slow that the user will just think it's frozen. If Emacs simply cannot handle large hscroll values, how about if we ceiling them out at some suitably-large value, say 1000? That would make this discussion moot and would make Emacs more robust in practice, as it'd prevent some freezes. Emacs already limits tab width in this way, so there's precedent. I can work on writing up a patch along these lines if you like. If we can't impose an arbitrary limit, then here are some more thoughts about the point at issue. Although it's true that in some cases Emacs happened to run incorrectly and quickly without the fix, in other cases Emacs ran incorrectly and froze whereas it now runs correctly and quickly (e.g., if the new hscroll is sufficiently negative). Since the patch fixes this bug without introducing new bugs it seems like a win. Besides, the previous paragraph assumes that signed integer overflow silently wraps around. This was formerly true of Emacs porting targets but is no longer true: overflow has undefined behavior, and can dump core or worse. Maybe the unfixed code happens to wrap around or dump core on all our porting targets when overflow occurs (which appears to be "acceptable" behavior here), but maybe it has even worse behavior, and it's not feasible to test whether it does. The fixed code doesn't have this problem. I sense a larger worry here that if we methodically change Emacs to prevent all cases of undefined behavior triggerable by converting Emacs fixnums to C integer values, then we'll have to add lots of checks that contort the C code so much as to make Emacs unmaintainable. If that's the worry, then there should be no need for concern, as no rewrite should be needed: the Emacs source code already has the desired property, modulo whatever minor bugs in this area still need fixing.