From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Assertion failure in set_iterator_to_next Date: Sun, 11 Apr 2010 16:04:05 -0400 Message-ID: References: <83633yznmf.fsf@gnu.org> <831velzwio.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1271016465 21302 80.91.229.12 (11 Apr 2010 20:07:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 11 Apr 2010 20:07:45 +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 Apr 11 22:07:44 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O13RW-0003Vs-VP for ged-emacs-devel@m.gmane.org; Sun, 11 Apr 2010 22:07:43 +0200 Original-Received: from localhost ([127.0.0.1]:55313 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O13RW-0002is-FY for ged-emacs-devel@m.gmane.org; Sun, 11 Apr 2010 16:07:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O13O8-0001gd-AS for emacs-devel@gnu.org; Sun, 11 Apr 2010 16:04:12 -0400 Original-Received: from [140.186.70.92] (port=51459 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O13O6-0001g2-D3 for emacs-devel@gnu.org; Sun, 11 Apr 2010 16:04:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O13O5-00016W-DC for emacs-devel@gnu.org; Sun, 11 Apr 2010 16:04:10 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:35173 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O13O3-00016E-9z; Sun, 11 Apr 2010 16:04:07 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGTHwUtMCqWu/2dsb2JhbACbRXK1Y4UMBItG X-IronPort-AV: E=Sophos;i="4.52,185,1270440000"; d="scan'208";a="60632536" Original-Received: from 76-10-165-174.dsl.teksavvy.com (HELO ceviche.home) ([76.10.165.174]) by ironport2-out.pppoe.ca with ESMTP; 11 Apr 2010 16:04:06 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id F3031660BF; Sun, 11 Apr 2010 16:04:05 -0400 (EDT) In-Reply-To: <831velzwio.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 11 Apr 2010 21:14:55 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:123498 Archived-At: >> > No, it->len should be the length of the multibyte sequence of the >> > character at IT_CHARPOS (*it). This is how the basic iteration works, >> > and if the length is incorrect, we will get garbled display, in >> > anything but pure 7-bit ASCII buffers. >> OK, good. Can you update/complete dispextern.h correspondingly? > Will do. Thanks. >> So the problem now is "why is it->len ==3 rather than ==1"? > I think it's because it was not yet updated. It is updated only in > the next_element_from_* functions. E.g., for a character from a > buffer, we have this in next_element_from_buffer: > /* Get the next character, maybe multibyte. */ > p = BYTE_POS_ADDR (IT_BYTEPOS (*it)); > if (it->multibyte_p && !ASCII_BYTE_P (*p)) > it-> c = STRING_CHAR_AND_LENGTH (p, it->len); <<<<<<<<< > else > it-> c = *p, it->len = 1; <<<<<<<<< Oh, thank you very much. I searched for this spot and couldn't find it (I grepped with a pattern like "->len =", which only caught the second line which couldn't explain why I was getting it->len==3. That should help me move forward. > Since you are saying this is an ASCII buffer, are charpos and bytepos > at least identical? Yes, they're identical before the assignment to IT_CHARPOS and IT_BYTEPOS, but since it->len==3 a discrepancy of 2 appears which then triggers the subsequent xassert. Stefan