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: Assertion failure in set_iterator_to_next Date: Sun, 11 Apr 2010 21:14:55 +0300 Message-ID: <831velzwio.fsf@gnu.org> References: <83633yznmf.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1271009705 31867 80.91.229.12 (11 Apr 2010 18:15:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 11 Apr 2010 18:15:05 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 11 20:15:04 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 1O11gU-0007jI-SJ for ged-emacs-devel@m.gmane.org; Sun, 11 Apr 2010 20:15:03 +0200 Original-Received: from localhost ([127.0.0.1]:38189 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O11gU-00051I-71 for ged-emacs-devel@m.gmane.org; Sun, 11 Apr 2010 14:15:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O11gP-00051C-BP for emacs-devel@gnu.org; Sun, 11 Apr 2010 14:14:57 -0400 Original-Received: from [140.186.70.92] (port=56599 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O11gO-000510-6m for emacs-devel@gnu.org; Sun, 11 Apr 2010 14:14:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O11gM-0001i9-Aa for emacs-devel@gnu.org; Sun, 11 Apr 2010 14:14:56 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:46325) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O11gM-0001hu-3y for emacs-devel@gnu.org; Sun, 11 Apr 2010 14:14:54 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0L0Q00B005BXCF00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sun, 11 Apr 2010 21:14:51 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.74.198]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L0Q005PK5CQJYF0@a-mtaout22.012.net.il>; Sun, 11 Apr 2010 21:14:51 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:123488 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Sun, 11 Apr 2010 11:02:22 -0400 > > > 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. > 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; <<<<<<<<< where I marked the 2 lines that update it->len. These functions are again called only from get_next_display_element, which was not yet called at the point where you have the faulting xassert. IOW, it->len is correct _before_ we advance to the next character, and it holds the length of the multibyte sequence of the character we already consumed, the one we are stepping over by incrementing bytepos by it->len. However, all this does not explain at all why you get the assertion failure, it just explains why neither the value of it->c nor it->len are relevant to the failure. All this notwithstanding, it is still true that `IT_BYTEPOS (*it) == CHAR_TO_BYTE (IT_CHARPOS (*it))', I think. Since you are saying this is an ASCII buffer, are charpos and bytepos at least identical? If they are, could it be that CHAR_TO_BYTE has a bug? If they are not identical, how large is the discrepancy?