From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: EMACS_INT vs int for range checking Date: Sun, 27 May 2012 09:19:10 +0300 Message-ID: <83vcjiuowx.fsf@gnu.org> References: <4FC09ECC.5050206@cs.ucla.edu> <8362bjw8t9.fsf@gnu.org> <4FC1298C.2090801@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1338099560 2337 80.91.229.3 (27 May 2012 06:19:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 27 May 2012 06:19:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 27 08:19:18 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 1SYWov-0007Bv-Mq for ged-emacs-devel@m.gmane.org; Sun, 27 May 2012 08:19:17 +0200 Original-Received: from localhost ([::1]:33209 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYWou-0003RN-Vk for ged-emacs-devel@m.gmane.org; Sun, 27 May 2012 02:19:16 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60627) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYWor-0003QY-AW for emacs-devel@gnu.org; Sun, 27 May 2012 02:19:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SYWop-0007Ut-08 for emacs-devel@gnu.org; Sun, 27 May 2012 02:19:12 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:60360) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYWoo-0007Uc-Oa for emacs-devel@gnu.org; Sun, 27 May 2012 02:19:10 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M4O00C003ROAP00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sun, 27 May 2012 09:19:09 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4O00C9847U6D50@a-mtaout20.012.net.il>; Sun, 27 May 2012 09:19:06 +0300 (IDT) In-reply-to: <4FC1298C.2090801@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.166 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:150654 Archived-At: > Date: Sat, 26 May 2012 12:05:48 -0700 > From: Paul Eggert > CC: emacs-devel@gnu.org > > Yes, but the current test does not reliably do that. On a 64-bit host > with 32-bit int it's possible, for example, that bidi_mirror_char can > return a garbage value. 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. Why should we abort in that case? > This is because assigning an out-of-int-range value to an 'int' > results in undefined behavior. How can that undefined behavior be any worse than aborting?? > 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.