bug#9642: move-overlay creates an empty overlay with the evaporate property

[Paul Eggert <eggert@cs.ucla.edu>]

On 10/01/11 01:22, Eli Zaretskii wrote:
> doing this invokes undefined behavior

No, everywhere else the overlay code consistently defines
the behavior: out-of-range values are treated as if they were
the nearest in-range values.  For example,

(make-overlay 0 (1+ (point-max)))

is treated exactly as if it were

(make-overlay 1 (point-max))

This is almost always true for move-overlay, too: for example,
in a nonempty buffer:

(move-overlay foo 0 (1+ (point-max)))

is exactly equivalent to

(move-overlay foo 1 (point-max))

This behavior is a longstanding Emacs tradition, in many functions,
e.g., (goto-char 0) is exactly equivalent to (goto-char 1).

I suppose it might make sense for the overlay code to consistently treat
out-of-range values as errors, and throw exceptions instead.
But what doesn't make sense is for the overlay behavior to be inconsistent,
where all the primitives follow goto-char's lead
except that in some (but not all) cases move-overlay screws up
and silently returns a bogus zero-length evaporating overlay.