From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#36431: Crash in marker.c:337 Date: Wed, 03 Jul 2019 07:49:13 +0300 Message-ID: <83lfxfd8om.fsf@gnu.org> References: <20190629.131734.877718102639559715.wl@gnu.org> <831rzch9nd.fsf@gnu.org> <83zhm0fuqg.fsf@gnu.org> <83ftnrf87e.fsf@gnu.org> <83v9wkcp3z.fsf@gnu.org> <83sgrocmws.fsf@gnu.org> <83pnmschvy.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="136660"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 36431@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 03 06:50:11 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hiXDd-000ZSP-TY for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Jul 2019 06:50:10 +0200 Original-Received: from localhost ([::1]:60704 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiXDc-0004xQ-VG for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Jul 2019 00:50:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58534) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiXDY-0004wx-1G for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2019 00:50:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hiXDW-00053k-Uv for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2019 00:50:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39475) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hiXDW-00053Y-Qm for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2019 00:50:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hiXDW-0007SN-Am for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2019 00:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Jul 2019 04:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36431 X-GNU-PR-Package: emacs Original-Received: via spool by 36431-submit@debbugs.gnu.org id=B36431.156212937428624 (code B ref 36431); Wed, 03 Jul 2019 04:50:02 +0000 Original-Received: (at 36431) by debbugs.gnu.org; 3 Jul 2019 04:49:34 +0000 Original-Received: from localhost ([127.0.0.1]:48296 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiXD3-0007Rc-VZ for submit@debbugs.gnu.org; Wed, 03 Jul 2019 00:49:34 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46116) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiXD2-0007RP-JC for 36431@debbugs.gnu.org; Wed, 03 Jul 2019 00:49:33 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34155) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hiXCw-0004ay-Aq; Wed, 03 Jul 2019 00:49:26 -0400 Original-Received: from [176.228.60.248] (port=1214 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hiXCv-0006Uy-SM; Wed, 03 Jul 2019 00:49:26 -0400 In-reply-to: (message from Stefan Monnier on Tue, 02 Jul 2019 17:00:21 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:162004 Archived-At: > From: Stefan Monnier > Cc: wl@gnu.org, 36431@debbugs.gnu.org > Date: Tue, 02 Jul 2019 17:00:21 -0400 > > > It says that (a) CODING->src_pos is the negative of the offset from > > GPT of where the bytes are in the gap > > Yes, I think this is actually wrong. You are right. > E.e. decode_coding_gap does: > > coding->src_chars = chars; > [...] > coding->src_pos = -chars; > > so nowhere does it account for unspecified number of bytes between the > beginning of the gap and the beginning of the source text. > Here, `src_pos` is the offset from the end of the gap. Yes, the clear evidence is in coding_set_source: if (coding->src_pos < 0) coding->source = BUF_GAP_END_ADDR (buf) + coding->src_pos_byte; (Note that it actually only uses the byte offset's numerical value. I couldn't find any place where it actually uses the character offset in src_pos, it only checks its sign.) > > As for why this was designed like that -- where else did you see > > comments in Emacs that answer this kind of questions? > > There are such design comments at various places. > Usually added after the fact, sometimes added as part of > a commit-reversal to make sure someone else doesn't fall into the same > trap ;-) Interesting. Can you point me to a couple of such design comments? > If CODING->src_object is a buffer, it must be the current buffer. > In this case, if CODING->src_pos is positive, it is a position of > the source text in the buffer, otherwise, the source text is in the > - gap area of the buffer, and CODING->src_pos specifies the offset of > - the text from GPT (which must be the same as PT). If this is the > - same buffer as CODING->dst_object, CODING->src_pos must be > - negative. > + gap area of the buffer, and CODING->src_pos specifies the > + offset of the text from the end of the gap (which must be at PT). The "which must be at PT" part is ambiguous. I suggest to say explicitly that the gap must be at PT (although decode-coding doesn't really blindly assume that, as you can see from its calls to move_gap_both). > + If this is the same buffer as CODING->dst_object, CODING->src_pos must > + be negative. I don't see the condition of the same buffer in the code. What did I miss? > + When the text is taken from the gap, it can't be at the beginning of > + the gap so that we can produce the decoded text at the beginning of > + the gap: this way, as the output grows, the input shrinks, so we only > + need to allocate enough space for `max(IN, OUT)` instead of `IN + OUT`. I think this should also tell that decoding in this setup takes bytes from encoded text at the end of the gap and inserts the decoded text starting at PT, which is the same as the beginning of the gap. Without saying that, the above paragraph might not be as clear as it should be.