From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Mon, 13 Oct 2014 14:35:02 +0900 Message-ID: <87ppdwo7ll.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87d2ahm3nw.fsf@fencepost.gnu.org> <871tqneyvl.fsf@netris.org> <87zjd9swfj.fsf@uwakimon.sk.tsukuba.ac.jp> <87oatnqpml.fsf@uwakimon.sk.tsukuba.ac.jp> <874mvdrj45.fsf@uwakimon.sk.tsukuba.ac.jp> <20141009044917.GA19957@fencepost.gnu.org> <83lhopisfr.fsf@gnu.org> <87ppe1pldu.fsf@uwakimon.sk.tsukuba.ac.jp> <8761ft5wpo.fsf@fencepost.gnu.org> <83k349b0vj.fsf@gnu.org> <83bnph96kh.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1413178556 18183 80.91.229.3 (13 Oct 2014 05:35:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Oct 2014 05:35:56 +0000 (UTC) Cc: dak@gnu.org, handa@gnu.org, mhw@netris.org, dmantipov@yandex.ru, emacs-devel@gnu.org, mikegerwitz@gnu.org, monnier@iro.umontreal.ca, Eli Zaretskii To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 13 07:35:48 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XdYIN-0006E0-9C for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 07:35:47 +0200 Original-Received: from localhost ([::1]:60268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdYIM-0003iO-U1 for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 01:35:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32933) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdYIC-0003i5-NU for emacs-devel@gnu.org; Mon, 13 Oct 2014 01:35:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdYI2-0000PD-Nm for emacs-devel@gnu.org; Mon, 13 Oct 2014 01:35:36 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:42270) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdYHh-0000Bi-U9; Mon, 13 Oct 2014 01:35:06 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 217631C3977; Mon, 13 Oct 2014 14:35:03 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 134E31A2888; Mon, 13 Oct 2014 14:35:03 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:175310 Archived-At: Richard Stallman writes: > I think the people who want strict encoding are talking about > network communication using open-network-stream. Speaking only for myself, no, I mean all octet streams purported to be encoded text, network or local. Network streams can only be considered safe in very carefully maintained environments, so the risks are greatest there. But there's no such thing as a truly local stream, since any given stream may be a file downloaded from the network or provided by an application of uncertain provenance. There are three cases of interest, AFAICS: (1) The file or application is truly local, provided with the OS or created by the user. In that case on a well-maintained system, the encoding should be valid, as you pointed out elsewhere. Therefore a strict policy should be transparent. (See (3) for what I believe to be the main class of exceptions.) (2) The file or application was downloaded from the network. Emacs cannot know the provenance, and so the same care should be taken as with a network stream. (3) The application is trustworthy, but produces invalid encoded text in some well-understood situations. In this case the Lisp program should be allowed to opt out of default validation and provide its own. Preferably only in the specific situations rather than globally. An example of (3) is David's case, with AUCTeX handling of TeX error messages containing non-unibyte text.) AFAIK such applications are quite rare nowadays. TeX is a special case because it is one of the few applications whose behavior is specified extremely precisely but in an encoding-oblivious way.[1] As an example of special validation in (3), AIUI in TeX error messages, only a very few leading and trailing bytes of quoted source text should be invalid. Thus the rest should be valid, and the user probably should be notified of unexpected rawbytes. (That's up to the Lisp programmer, of course. Still I think such flexible validation is in the user's interest if the programmer is willing to provide it.) I am unaware of other large classes of exceptional cases in modern GNU/Linux systems, or the major proprietary OSes. I understand David and Eli to be of the opinion that in practice there is insignificant risk to Emacs or its users from any form of invalid or malicious input, from the network or local. I disagree. Footnotes: [1] I'm referring to the TRIP test. This specification effectively assumes a unibyte encoding, and so it is likely to be very difficult to create a TeX implementation that handles Unicode conformant to the standard *and* passes TRIP. I'll take a TeX that passes TRIP any day!