Re: Should undefined behavior be encouraged in Emacs?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 03 Oct 2011 09:13:08 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> 
>     My impression is that Emacs built-ins are generally supposed to
>     have defined behavior, so that Emacs is easier to use reliably.
> 
> What is the meaning of "defined" or "undefined", here?
> Is it a matter of whether the documentation says what happens in that case?

Undefined behavior is something that is left to the implementation,
and the programmer who invokes it cannot expect anything in
particular.  Examples (from C) are use of an automatic variable before
initializing it, indexing an array outside of its bounds, etc.  These
could work, or they could produce strange results, or they could
crash.

I consider referencing buffer position of zero similar to indexing an
array out of its bounds.

> In simple cases such as (goto-char -5), users tend to see what the
> behavior is, and are likely to write code that depends on it, even if
> it isn't documented.  Thus, leaving it undocumented doesn't mean that
> we can change it and nobody will notice.
> 
> Meanwhile, even if something is documented, we CAN change it.
> It just means somewhat more annoyance will occur.

Documentation is not the issue here.  The issue is whether we should
let people expect certain undefined behaviors and demand that any such
behavior invariably produces results they expect.  To continue one of
the above examples, the expectation that an uninitialized automatic
variable in a C program always has the value of zero, or that
accessing an array out of bounds actually access its first or last
element, whichever is closest to the invalid reference.

When a large enough body of Lisp programs has been written that relies
on such behavior, any significant changes in the underlying
implementation are either very hard or very bug-prone (or both),
because no living individual can possibly study enough Lisp programs
to glean all these expectations and design the modified implementation
so as not to break them.