From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#36431: Crash in marker.c:337 Date: Tue, 02 Jul 2019 17:00:21 -0400 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="195032"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 36431@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 02 23:01:46 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 1hiPuL-000ocJ-QI for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Jul 2019 23:01:45 +0200 Original-Received: from localhost ([::1]:57568 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiPuK-0007PC-Si for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Jul 2019 17:01:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44238) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiPu5-0007MO-36 for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 17:01:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hiPtn-0002i6-OA for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 17:01:15 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39246) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hiPte-0002eI-R0 for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 17:01:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hiPtd-0002Xb-Js for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 17:01:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Jul 2019 21:01:01 +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.15621012439736 (code B ref 36431); Tue, 02 Jul 2019 21:01:01 +0000 Original-Received: (at 36431) by debbugs.gnu.org; 2 Jul 2019 21:00:43 +0000 Original-Received: from localhost ([127.0.0.1]:48067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiPtL-0002Wy-3O for submit@debbugs.gnu.org; Tue, 02 Jul 2019 17:00:43 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:20412) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiPtH-0002Wi-Nz for 36431@debbugs.gnu.org; Tue, 02 Jul 2019 17:00:40 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 91544100B3B; Tue, 2 Jul 2019 17:00:32 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1A9A51009BB; Tue, 2 Jul 2019 17:00:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1562101231; bh=bfFJ8askGBpx65ZREkyDepBaopvf4JQDmKjiLs+yJQ0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=E5Va/pVAR+55Nwbw6MKumJpN8FmBYTzdW5ojCgXhDdqA1dcqyMd4uMbpo834Rfu47 ZcfbO18a92TrwxNEHgPxBXCWm27A+LwT/TVz2qm3SG2ypX0Bm5Ac2C3QOmkgjMH4XG jcxBZ5udhMrHmpi4C/hiNzTc5AMdEeGGDEQDBBQk2jU0lg4tb/QUGcJe0qSPZfQ2f0 3R8ARWnW7K158JVeBfZF9cUKfR+ncEurc3mXEwP11M641Z6yuX8aJ6WQ49fKxZluiw nJkE4LYVsertLPgwfmPmm1HDYsg7x+5z28hGDQSLOsWRtOuvfn5lgCkaHJmUauFAtK kVJ0dlohOQcxA== Original-Received: from alfajor (76-10-151-214.dsl.teksavvy.com [76.10.151.214]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9F9491201F1; Tue, 2 Jul 2019 17:00:30 -0400 (EDT) In-Reply-To: <83pnmschvy.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Jul 2019 23:15:45 +0300") 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:161993 Archived-At: >> Decode the data at CODING->src_object into CODING->dst_object. >> CODING->src_object is a buffer, a string, or nil. >> CODING->dst_object is a buffer. >> >> 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. >> [...] >> The decoded data is inserted at the current point of the buffer >> CODING->dst_object. >> >> but this doesn't say if the bytes are to be found originally at the >> beginning of the gap or its end, nor whether they finish at the beginning or >> the end, nor what happens in the middle and why it's been designed this way. > > 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. 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. > (they don't have to be "at the > end", AFAIU, just not "at the beginning"); Oh, indeed, src_pos doesn't need to start as the negation of src_chars. > 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 ;-) >> Is the patch below correct? > I think it describes conditions that don't need to exist. How 'bout this new version. Stefan diff --git a/src/coding.c b/src/coding.c index 59589caee6..fd7e7aca0f 100644 --- a/src/coding.c +++ b/src/coding.c @@ -7323,10 +7323,15 @@ produce_annotation (struct coding_system *coding, ptrdiff_t pos) 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). + If this is the same buffer as CODING->dst_object, CODING->src_pos must + be negative. + + 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`. If CODING->src_object is a string, CODING->src_pos is an index to that string.