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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: acm <at> muc.de, monnier <at> iro.umontreal.ca, 49944 <at> debbugs.gnu.org
Subject: Re: bug#49944: parse-partial-sexp fails to signal an error when (>
 START LIMIT).
Date: Tue, 10 Aug 2021 18:36:33 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  acm <at> muc.de,  49944 <at> debbugs.gnu.org
> Date: Tue, 10 Aug 2021 16:54:59 +0200
> 
> > So, I don't care if we signal an error when START > END or if we "do
> > nothing" (as is customary in some language's `for` loops), but we should
> > always consider that OLDSTATE is the state that belongs with START and
> > hence we can't start parsing at END towards START because we don't know
> > what parsing state to use at END.
> 
> Ah; thanks for the explanation.
> 
> But I guess you'll get incorrect results if you pass in any OLDSTATE
> that doesn't belong to START, not just when START and END are swapped?
> It's just that if START/END obviously wrong (i.e., END is smaller than
> START), then the function here "helpfully" swaps them and things get
> even more confusing than they would normally be if you pass in a wrong
> OLDSTATE (or wrong START).
> 
> So perhaps signalling an error here is the correct thing after all?  (Or
> just not doing any swapping.)

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?

Previous Next

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