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 19:33:22 +0300 Message-ID: <83o92baxil.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> <83lfxfd8om.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="235376"; 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 18:50:42 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 1hiiSw-000z5v-80 for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Jul 2019 18:50:42 +0200 Original-Received: from localhost ([::1]:37534 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiiFg-000477-Sn for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Jul 2019 12:37:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36091) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiiCp-0001y0-Su for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2019 12:34:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hiiCo-0006WA-Kv for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2019 12:34:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41127) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hiiCo-0006Vy-Ha for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2019 12:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hiiCo-0003je-9q for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2019 12:34: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 16:34: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.156217162914338 (code B ref 36431); Wed, 03 Jul 2019 16:34:02 +0000 Original-Received: (at 36431) by debbugs.gnu.org; 3 Jul 2019 16:33:49 +0000 Original-Received: from localhost ([127.0.0.1]:49948 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiiCa-0003jB-M8 for submit@debbugs.gnu.org; Wed, 03 Jul 2019 12:33:49 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51750) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiiCY-0003iy-Dx for 36431@debbugs.gnu.org; Wed, 03 Jul 2019 12:33:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44244) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hiiCO-0006AX-DR; Wed, 03 Jul 2019 12:33:38 -0400 Original-Received: from [176.228.60.248] (port=2491 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hiiCN-00071X-K7; Wed, 03 Jul 2019 12:33:36 -0400 In-reply-to: (message from Stefan Monnier on Wed, 03 Jul 2019 12:19:22 -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:162026 Archived-At: > From: Stefan Monnier > Cc: wl@gnu.org, 36431@debbugs.gnu.org > Date: Wed, 03 Jul 2019 12:19:22 -0400 > > > (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.) > > The source is required to be unibyte, so src_pos and src_pos_byte have > to be equal at start and one of the two is redundant. My point was that the code uses the sign of one of them and the value of the other. > >> + 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 > > AFAICT that's exactly what it is saying, so I'm not sure what ambiguity > you're thinking of. The text could be interpreted as meaning that the end of the gap must be at PT. IOW, "which" could either allude to the gap or to the end of the gap. > > (although decode-coding doesn't really blindly assume that, as you can > > see from its calls to move_gap_both). > > [ FWIW, this part of the text is mostly preserved from the old text. ] I assumed that you wanted to clarify the comment, so preserving old text sounds like a non-goal ;-) > I think the issue is that decode_coding's calls to move_gap_both *must* > be no-ops when the source is in the gap otherwise it'll destroy the > source-text. No, I meant the code there actually tests these conditions, and if they are not true, it moves the gap as needed to make them true. > >> + 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? > > This one I don't know: I just preserved this part of the text. I don't think it's true. CODING->src_pos must be negative if the source text is in the gap, period. > >> + 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. > > [ PT is both the beginning and the end of the gap ;-) ] Not in what I wrote, AFAICT.