From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Should undefined behavior be encouraged in Emacs? Date: Mon, 03 Oct 2011 05:52:15 -0400 Message-ID: References: <4E89124D.8070405@cs.ucla.edu> <20111003092046.GA3248@acm.acm> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1317635551 12559 80.91.229.12 (3 Oct 2011 09:52:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 3 Oct 2011 09:52:31 +0000 (UTC) Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 03 11:52:24 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 1RAfCB-0007NU-5s for ged-emacs-devel@m.gmane.org; Mon, 03 Oct 2011 11:52:23 +0200 Original-Received: from localhost ([::1]:35389 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAfCA-0002i6-Fo for ged-emacs-devel@m.gmane.org; Mon, 03 Oct 2011 05:52:22 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:57941) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAfC7-0002hj-Ls for emacs-devel@gnu.org; Mon, 03 Oct 2011 05:52:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RAfC6-0005IF-0u for emacs-devel@gnu.org; Mon, 03 Oct 2011 05:52:19 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:36803) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAfC5-0005I7-RX for emacs-devel@gnu.org; Mon, 03 Oct 2011 05:52:17 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RAfC3-0007vG-ML; Mon, 03 Oct 2011 05:52:15 -0400 In-reply-to: <20111003092046.GA3248@acm.acm> (message from Alan Mackenzie on Mon, 3 Oct 2011 09:20:46 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:144538 Archived-At: > Date: Mon, 3 Oct 2011 09:20:46 +0000 > From: Alan Mackenzie > Cc: Paul Eggert , Emacs Development > > Hi, Stefan. > > On Sun, Oct 02, 2011 at 11:11:58PM -0400, Stefan Monnier wrote: > > > The argument given for undefined behavior is that it simplifies > > > maintenance of Emacs internals. > > > I like to keep some corner of the behavior undefined, when I think > > that user code that depends on such details is undesirable (e.g. return > > values of primitives which are only called for side-effects). > > There are few functions called solely for side effects. For example, > `goto-char' is frequently found thusly: > ... > Surely the return value of things like `goto-char' should be > defined? Since this discussion is about to veer sideways, I'd like to make it clear that I didn't mean something like goto-char's return value at all. What I meant is the behavior of Lisp primitives and subroutines when they are called with invalid arguments, such as buffer positions that are non-positive. The original example was that an overlay was moved to start at position zero and end on position 1, and Paul wanted such an overlay to be considered empty, because he _expected_ position zero to be always treated as position 1.