GNU bug report logs - #40000
27.0.60; next-single-char-property-change hangs on bad argument

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: casouri <at> gmail.com, 40000 <at> debbugs.gnu.org
Subject: Re: bug#40000: 27.0.60;
 next-single-char-property-change hangs on bad argument
Date: Mon, 13 Apr 2020 17:31:29 +0300

> From: Federico Tedin <federicotedin <at> gmail.com>
> Cc: casouri <at> gmail.com,  40000 <at> debbugs.gnu.org
> Date: Mon, 13 Apr 2020 16:20:01 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >   If the property is constant all the way to the end of OBJECT, return the
> >   last valid position in OBJECT.
> >
> > Your change means this will no longer be true when LIMIT > EOB.
> >
> > Thanks.
> 
> Aah OK, I missed that part at the end. But if I evaluate:
> 
>   (next-single-char-property-change 0 'test "hello" 10000)
> 
> It still returns 10000. Is it possible that "return LIMIT if nothing is
> found before LIMIT" is meant to take precedence over "return the last
> valid position in OBJECT"?

I think this means you are dealing with "undefined behavior".  Since
you want to make it well-defined, the results must be consistent,
where they weren't before.

Note that the doc string also says this:

  In a string, scan runs to the end of the string, unless LIMIT is non-nil.
  In a buffer, if LIMIT is nil or omitted, it runs to (point-max), and the
  value cannot exceed that.

So it's quite clear to me that the value should never be more than the
last valid position, both for strings and for buffers.  No doubt, no
one called this function with LIMIT beyond the last valid position,
because that would produce an infloop.  So a change that will return
the maximum valid position in this case cannot be
backward-incompatible.

Previous Next

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