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

[Alan Mackenzie <acm@muc.de>]

Hello, Lars.

On Sun, Aug 08, 2021 at 20:14:25 +0200, Lars Ingebrigtsen wrote:
> Alan Mackenzie <acm@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).