From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#49944: parse-partial-sexp fails to signal an error when (> START LIMIT). Date: Tue, 10 Aug 2021 19:38:51 +0300 Message-ID: <83czqlfe5g.fsf@gnu.org> References: <87r1f36by6.fsf@gnus.org> <87pmum4wnm.fsf@gnus.org> <87a6lpz9vq.fsf@gnus.org> <83mtppflcu.fsf@gnu.org> <87o8a5xscc.fsf@gnus.org> <83k0ktfh1a.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34951"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, larsi@gnus.org, 49944@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 10 18:39:18 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mDUmc-0008p4-6X for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 10 Aug 2021 18:39:18 +0200 Original-Received: from localhost ([::1]:54704 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mDUmV-0004Hy-H3 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 10 Aug 2021 12:39:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34404) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mDUmN-0004HA-QB for bug-gnu-emacs@gnu.org; Tue, 10 Aug 2021 12:39:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49171) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mDUmM-0001zG-H1 for bug-gnu-emacs@gnu.org; Tue, 10 Aug 2021 12:39:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mDUmM-0008J9-EM for bug-gnu-emacs@gnu.org; Tue, 10 Aug 2021 12:39: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: Tue, 10 Aug 2021 16:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49944 X-GNU-PR-Package: emacs Original-Received: via spool by 49944-submit@debbugs.gnu.org id=B49944.162861352731913 (code B ref 49944); Tue, 10 Aug 2021 16:39:02 +0000 Original-Received: (at 49944) by debbugs.gnu.org; 10 Aug 2021 16:38:47 +0000 Original-Received: from localhost ([127.0.0.1]:60717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mDUm7-0008If-56 for submit@debbugs.gnu.org; Tue, 10 Aug 2021 12:38:47 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53732) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mDUm5-0008IT-MN for 49944@debbugs.gnu.org; Tue, 10 Aug 2021 12:38:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:56898) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mDUlz-0001if-P1; Tue, 10 Aug 2021 12:38:39 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4319 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mDUlz-0006Ev-CB; Tue, 10 Aug 2021 12:38:39 -0400 In-Reply-To: (message from Stefan Monnier on Tue, 10 Aug 2021 11:44:55 -0400) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:211532 Archived-At: > From: Stefan Monnier > Cc: Lars Ingebrigtsen , acm@muc.de, 49944@debbugs.gnu.org > Date: Tue, 10 Aug 2021 11:44:55 -0400 > > > The reordering is the side effect of calling validate_region, so we'd > > need to expend extra effort NOT to reorder START and END. > > > > How about just documenting that OLDSTATE should be the state at START, > > and that's it? > > The current use of `validate_region` means that OLDSTATE will be used as > the state at "either FROM or TO, whichever is smaller". > > So I don't understand what it is you're proposing: if we document > that OLDSTATE should be the state at FROM, then we need to change the > code so that it never swaps FROM and TO. And if we don't want to change > the code, then we should document that OLDSTATE will be used as the > state at TO when TO is smaller than FROM. The latter. By documenting the expectations of the function, we leave it to the callers to make sure their code works as intended.