GNU bug report logs - #49944
parse-partial-sexp fails to signal an error when (> START LIMIT).

Previous Next

Package: emacs;

Reported by: Alan Mackenzie <acm <at> muc.de>

Date: Sun, 8 Aug 2021 18:02:01 UTC

Severity: normal

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #11 received at 49944 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 49944 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#49944: parse-partial-sexp fails to signal an error when (>
 START LIMIT).
Date: Sun, 8 Aug 2021 18:51:27 +0000
Hello, Lars.

On Sun, Aug 08, 2021 at 20:14:25 +0200, Lars Ingebrigtsen wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

> > On calling
> >
> >     (parse-partial-sexp 19 18 nil nil s)

> (What's `s' here?)

Sorry, should have said.  It was a syntax state at position 19,
something like:

    (0 nil 8 34 nil nil 0 nil 13 nil nil)

representing a "normal" string starting at position 13.

> > Emacs surely ought to signal an error, since 18 < 19.

> It's common for Emacs functions that take a region to not care about
> whether to is larger than from or not.

parse-partial-sexp doesn't work on a region.  It works with a starting
position and ending position, which are not interchangeable.  For
example, the status s (above) is the status at 19, not at 18.

> The

>   validate_region (&from, &to);

> function fixes it up.

It doesn't fix it up, it messes it up.

> > It doesn't,
> > though.  It leaves point at a random position and returns
> >
> >     (0 nil nil nil nil nil 0 nil nil nil nil)

> For me it leaves point at 19.

I think it may have done that for me, too, though perhaps not every
time.

Getting back on topic, I think there are no legitimate uses for (> start
limit), and every such call is a bug.  It would seem such a call
discards the input state argument, which would be a bug in itself if the
whole thing weren't a bug.

It's obvious to me that Emacs should throw an error in these
circumstances.  You seem to be disagreeing, or at least to be unsure.
One data point is it took me over an hour's time to track it down, time
that could have been better spent if Emacs had thrown an error.

> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no

-- 
Alan Mackenzie (Nuremberg, Germany).




This bug report was last modified 3 years and 272 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.