From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Monnier Subject: =?UTF-8?B?YnVnIzIzOTE3OiBQbGVhc2UgY29uc2lkZXIgbWFraW5nIEJ1ZyAj?= =?UTF-8?B?MjM5MTcgYSBibG9ja2VyIGZvciAyNS4xICh3YXMgUmU6IG9yZy1jYXB0dXJl?= =?UTF-8?B?OiBDYXB0dXJlIHRlbXBsYXRlIOKAmGfigJk6IE1hdGNoIGRhdGEgY2xvYmJl?= =?UTF-8?B?cmVkIGJ5IGJ1ZmZlciBtb2RpZmljYXRpb24gaG9va3Mp?= Date: Tue, 19 Jul 2016 00:48:19 -0400 Message-ID: References: <87vb066ejv.fsf@linaro.org> <8360s67qcp.fsf@gnu.org> <87bn1yyaui.fsf@linaro.org> <87mvlhmv0x.fsf_-_@moondust.awandering> <837fcl5zs9.fsf@gnu.org> <87a8hgkwcb.fsf@linaro.org> <8360s42mcb.fsf@gnu.org> <87eg6rgmlg.fsf@gmail.com> <83lh0y24y6.fsf@gnu.org> <83eg6q1hbo.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42631) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPMy2-0005Gk-34 for emacs-orgmode@gnu.org; Tue, 19 Jul 2016 00:49:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPMy1-0002jm-4M for emacs-orgmode@gnu.org; Tue, 19 Jul 2016 00:49:14 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <83eg6q1hbo.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 19 Jul 2016 05:40:11 +0300") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Eli Zaretskii Cc: 23917@debbugs.gnu.org, rpluim@gmail.com, jwiegley@gmail.com, alex.bennee@linaro.org, nljlistbox2@gmail.com > The more general problem is when there's at least one more > sub-expression, whose start and/or end are after the new EOB. > Those sub-expression's data will be completely bogus after the > adjustment, If they were after the EOB, they were already bogus to start with. So there's really not much harm moving them around. And in any case, that's what has been happening for ever and has proved safe enough. >> So I think a safe fix is to try and relax the check we added to >> replace-match so it doesn't get all worked up when something =E2=89=A5 E= OB gets >> changed to something else that's also =E2=89=A5 EOB. > And lose the other sub-expressions in a more general case? Really? I'm not sure what you mean by "losing sub-expressions". But yes, I think the behavior of save-match-data you describe is not a real problem. Arguably if save-match-data moves positions from outside BEGV...ZV to inside it it's a problem. But if it moves them from outside BEG...Z to inside it, I think it's perfectly fine. >> Or maybe instead of signaling an error, we could simply skip the "Adjust >> search data for this change". > That would still sweep the problem under the carpet, leaving the match > data bogus, so I don't like doing that. Maybe I'm not 100% satisfied with the behavior either, but I don't think it's a significant problem and I don't think it'd cause the crash we saw in bug#23869. > The crash in bug#23869 was due to this: > > newpoint =3D search_regs.start[sub] + SCHARS (newtext); > [...] > /* Now move point "officially" to the start of the inserted replacement= . */ > move_if_not_intangible (newpoint); <<<<<<<<<<<<<<<<<<<<<<< > > because due to clobbering, newpoint became -1. Ah, I see. Then maybe another fix is to compute newpoint before we call replace_range, so it uses search_regs.start[sub] before the *-change-functions can mess it up. IOW: @@ -2726,9 +2726,9 @@ since only regular expressions have distinguished= subexpressions. */) unsigned num_regs =3D search_regs.num_regs; =20=20=20=20=20 /* Replace the old text with the new in the cleanest possible way. = */ + newpoint =3D search_regs.start[sub] + SCHARS (newtext); replace_range (search_regs.start[sub], search_regs.end[sub], newtext, 1, 0, 1); - newpoint =3D search_regs.start[sub] + SCHARS (newtext); =20=20=20=20=20 if (case_action =3D=3D all_caps) Fupcase_region (make_number (search_regs.start[sub]), Would that be sufficient to avoid the crash? Why not? Stefan