Re: Should undefined behavior be encouraged in Emacs?

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

On 10/03/11 06:13, Richard Stallman wrote:

> What is the meaning of "defined" or "undefined", here?
> Is it a matter of whether the documentation says what happens in that case?

Partly that, but the question is more about what's reasonable when
behavior is not documented.

For example, there's no documentation for what (make-hash-table :size 0)
does.  If we are very strict and say that the behavior is completely
undefined, then (make-hash-table :size 0) might:

 (a) signal an error
 (b) act like (make-hash-table :size 1)
 (c) return nil
 (d) cause Emacs to exit with status 127
 (e) modify a randomly-chosen string somewhere in your program
 (f) create a hash table that later doesn't work
 (g) corrupt the contents of the file ~/.emacs
 (h) dump core

(a), (b), and (c) are common choices for Emacs built-ins, and I
expect we agree these behaviors are OK.  Conversely, we agree that
(h) is not OK.

The question is whether actions like (d) through (g) are OK for
built-ins that are given out-of-range values, and for similar
areas where behavior is not documented.  If the answer is "yes",
it will be easier to maintain Emacs's internals; if "no",
Emacs will be easier to use reliably.