From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Is CHAR_TO_BYTE considered to have no side-effects? Date: Wed, 17 Apr 2002 16:30:19 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <20020417162147.20D9.LEKTU@terra.es> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1019054188 27087 127.0.0.1 (17 Apr 2002 14:36:28 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 17 Apr 2002 14:36:28 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16xqXs-00072m-00 for ; Wed, 17 Apr 2002 16:36:28 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16xqqb-0004Bk-00 for ; Wed, 17 Apr 2002 16:55:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16xqUd-00047v-00; Wed, 17 Apr 2002 10:33:07 -0400 Original-Received: from [62.22.27.141] (helo=mail.peoplecall.com) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16xqRy-0002PP-00 for ; Wed, 17 Apr 2002 10:30:22 -0400 Original-Received: from jbarranquero (jbarranquero.ofi.peoplecall.com [62.22.27.143]) by mail.peoplecall.com (8.11.6/8.11.6) with ESMTP id g3HEUHA12025 for ; Wed, 17 Apr 2002 16:30:17 +0200 Original-To: emacs-devel@gnu.org X-Mailer: Becky! ver. 2.00.10 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2701 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2701 The following patch removes two unused local variables from current_column_1 and Fmove_to_column, but is is conditional on supposing CHAR_TO_BYTE has no side effects. In fact it can have, has CHAR_TO_BYTE hides a call to buf_charpos_to_bytepos, which in turn can potentially make things like creating (short-lived) markers for caching, etc. So, can CHAR_TO_BYTE be considered, interface-wise, as side-effect free? /L/e/k/t/u Index: indent.c =================================================================== RCS file: /cvs/emacs/src/indent.c,v retrieving revision 1.148 diff -u -r1.148 indent.c --- indent.c 17 Apr 2002 14:19:00 -0000 1.148 +++ indent.c 17 Apr 2002 14:20:46 -0000 @@ -512,7 +512,7 @@ /* Start the scan at the beginning of this line with column number 0. */ register int col = 0; int scan, scan_byte; - int next_boundary, next_boundary_byte; + int next_boundary; int opoint = PT, opoint_byte = PT_BYTE; scan_newline (PT, PT_BYTE, BEGV, BEGV_BYTE, -1, 1); @@ -520,7 +520,6 @@ scan = PT, scan_byte = PT_BYTE; SET_PT_BOTH (opoint, opoint_byte); next_boundary = scan; - next_boundary_byte = scan_byte; if (tab_width <= 0 || tab_width > 1000) tab_width = 8; @@ -540,7 +539,6 @@ goto endloop; if (scan != old_scan) scan_byte = CHAR_TO_BYTE (scan); - next_boundary_byte = CHAR_TO_BYTE (next_boundary); } /* Check composition sequence. */ @@ -937,8 +935,7 @@ int prev_col = 0; int c = 0; int next_boundary; - - int pos_byte, next_boundary_byte; + int pos_byte; if (tab_width <= 0 || tab_width > 1000) tab_width = 8; CHECK_NATNUM (column); @@ -948,7 +945,6 @@ pos_byte = PT_BYTE; end = ZV; next_boundary = pos; - next_boundary_byte = PT_BYTE; /* If we're starting past the desired column, back up to beginning of line and scan from there. */ @@ -968,7 +964,6 @@ pos = skip_invisible (pos, &next_boundary, end, Qnil); if (pos != prev) pos_byte = CHAR_TO_BYTE (pos); - next_boundary_byte = CHAR_TO_BYTE (next_boundary); if (pos >= end) goto endloop; }