Should undefined behavior be encouraged in Emacs?

[Paul Eggert]

Bug#9642 has raised a question about Emacs design philosophy.

Some Emacs built-ins treat an out-of-range argument as the nearest
value in range.  For example, (goto-char -5) acts like (goto-char 1),
and (make-overlay -5 1) acts like (make-overlay 1 1), because -5
is out of the range of valid buffer positions.  Other built-ins
signal an exception: for example, (aref "abc" -5) signals an
error, and (forward-char -5) signals an error at buffer start.
And still others wrap around: for example, (- most-negative-fixnum)
yields most-negative-fixnum.

A recent comment in Bug#9642 advocates another approach: undefined
behavior.  For example, it proposes that move-overlay should have
undefined behavior when given arguments like -5 that are out of
range.  In other words, (move-overlay OVERLAY -5 1) might signal
an error, or substitute an in-range value, or wrap around, or
return a data structure that subtly violates some other guarantee
made by Emacs; or it might do one of these things sometimes and
another at other times.  In short, undefined behavior means that
move-overlay might do *anything* when given out-of-range
arguments.

The argument given for undefined behavior is that it simplifies
maintenance of Emacs internals.

My impression is that Emacs built-ins are generally supposed to
have defined behavior, so that Emacs is easier to use reliably.
But another developer apparently disagrees, so thought I'd ask on
emacs-devel for further comments.

Here's the a pointer to the abovementioned comment:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9642#23