From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Should undefined behavior be encouraged in Emacs? Date: Mon, 03 Oct 2011 13:53:09 -0700 Organization: UCLA Computer Science Department Message-ID: <4E8A20B5.4060504@cs.ucla.edu> References: <4E89124D.8070405@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1317675219 26242 80.91.229.12 (3 Oct 2011 20:53:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 3 Oct 2011 20:53:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 03 22:53:35 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RApW3-0004iE-42 for ged-emacs-devel@m.gmane.org; Mon, 03 Oct 2011 22:53:35 +0200 Original-Received: from localhost ([::1]:49612 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RApW2-00017j-CV for ged-emacs-devel@m.gmane.org; Mon, 03 Oct 2011 16:53:34 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:54749) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RApVu-00010O-Rt for emacs-devel@gnu.org; Mon, 03 Oct 2011 16:53:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RApVt-00033e-D9 for emacs-devel@gnu.org; Mon, 03 Oct 2011 16:53:26 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:46104) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RApVt-00033I-7q; Mon, 03 Oct 2011 16:53:25 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id D6697A60047; Mon, 3 Oct 2011 13:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiYItX7-hUqb; Mon, 3 Oct 2011 13:53:15 -0700 (PDT) Original-Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 4DAA139E80D2; Mon, 3 Oct 2011 13:53:15 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.22) Gecko/20110906 Fedora/3.1.14-1.fc14 Thunderbird/3.1.14 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 131.179.128.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:144555 Archived-At: 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.