[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Should undefined behavior be encouraged in Emacs?

From: Paul Eggert
Subject: Re: Should undefined behavior be encouraged in Emacs?
Date: Mon, 03 Oct 2011 13:53:09 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110906 Fedora/3.1.14-1.fc14 Thunderbird/3.1.14

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]