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: EMACS_INT vs int for range checking Date: Sun, 27 May 2012 00:34:39 -0700 Organization: UCLA Computer Science Department Message-ID: <4FC1D90F.200@cs.ucla.edu> References: <4FC09ECC.5050206@cs.ucla.edu> <8362bjw8t9.fsf@gnu.org> <4FC1298C.2090801@cs.ucla.edu> <83vcjiuowx.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 1338104092 27577 80.91.229.3 (27 May 2012 07:34:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 27 May 2012 07:34:52 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 27 09:34:52 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 1SYXzy-0008AD-Ff for ged-emacs-devel@m.gmane.org; Sun, 27 May 2012 09:34:46 +0200 Original-Received: from localhost ([::1]:41374 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYXzy-00047m-5r for ged-emacs-devel@m.gmane.org; Sun, 27 May 2012 03:34:46 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39016) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYXzv-00047d-0E for emacs-devel@gnu.org; Sun, 27 May 2012 03:34:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SYXzt-000363-08 for emacs-devel@gnu.org; Sun, 27 May 2012 03:34:42 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:47755) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYXzq-00035S-C2; Sun, 27 May 2012 03:34:38 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 17D6EA60010; Sun, 27 May 2012 00:34:36 -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 8HWikVrzrgl0; Sun, 27 May 2012 00:34:35 -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 8CA12A6000E; Sun, 27 May 2012 00:34:35 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 In-Reply-To: <83vcjiuowx.fsf@gnu.org> 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:150655 Archived-At: On 05/26/2012 11:19 PM, Eli Zaretskii wrote: > If that garbage passes the [0..MAX_CHAR] test, it's garbage that the > bidi reordering engine and the rest of redisplay can live with. No, because the rest of redisplay cannot live with undefined behavior. For example, the generated machine code could use 32-bit comparison within bidi_mirror_char, so that (v < 0 || v > MAX_CHAR) yields false, but return an untruncated 64-bit value to the caller, so that the returned value exceeds MAX_CHAR and messes up the caller. > How can that undefined behavior be any worse than aborting? When the undefined behavior doesn't abort -- when it goes on to cause subtle errors in later computation. >> If it's the EMACS_INT that's annoying, how about this further patch? >> It shortens and clarifies the source code and fixes the portability problem. > > I will only accept such a test as an eassert. This code is in the > innermost loop of the Emacs display engine, so doing all that juggling > in an optimized build _for_every_character_we_display_ is unacceptable. OK, thanks, I installed it as an eassert. (Though the code runs equally fast either way with any decent modern compiler, as most of CHAR_VALID_P is optimized away.)