bug#40000: 27.0.60; next-single-char-property-change hangs on bad argument

[Federico Tedin]

> 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.

I agree that the function should always return equal or smaller than the
last valid position. In case of buffers, fixing LIMIT > (point-max) is
OK because the function wasn't defined for that case anyways, as you
mentioned. However I'm not sure if my patch should fix the case for
strings where LIMIT > (length object), since that would mean that the
returned value would now be (length object) instead of LIMIT. And calls
to this function with these types of values could already exist, since
in this case the function did not hang.