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: Sun, 05 Oct 2014 19:43:05 +0900 Message-ID: <877g0eu79i.fsf@uwakimon.sk.tsukuba.ac.jp> References: <54193A70.9020901@member.fsf.org> <87lhp6h4zb.fsf@panthera.terpri.org> <87k34qo4c1.fsf@fencepost.gnu.org> <54257C22.2000806@yandex.ru> <83iokato6x.fsf@gnu.org> <87wq8pwjen.fsf@uwakimon.sk.tsukuba.ac.jp> <837g0ptnlj.fsf@gnu.org> <87r3yxwdr6.fsf@uwakimon.sk.tsukuba.ac.jp> <87tx3tmi3t.fsf@fencepost.gnu.org> <834mvttgsf.fsf@gnu.org> <87lhp5m99w.fsf@fencepost.gnu.org> <87h9ztm5oa.fsf@fencepost.gnu.org> <87d2ahm3nw.fsf@fencepost.gnu.org> <871tqneyvl.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1412505846 1086 80.91.229.3 (5 Oct 2014 10:44:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Oct 2014 10:44:06 +0000 (UTC) Cc: dak@gnu.org, Richard Stallman , dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, Stefan Monnier , eliz@gnu.org To: Mark H Weaver Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 05 12:43:58 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 1XajIE-0004Ln-K7 for ged-emacs-devel@m.gmane.org; Sun, 05 Oct 2014 12:43:58 +0200 Original-Received: from localhost ([::1]:46975 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XajIE-00071v-4T for ged-emacs-devel@m.gmane.org; Sun, 05 Oct 2014 06:43:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35726) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XajHt-00070y-GX for emacs-devel@gnu.org; Sun, 05 Oct 2014 06:43:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XajHl-0005Nj-OD for emacs-devel@gnu.org; Sun, 05 Oct 2014 06:43:37 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:43787) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XajHW-0004sK-05; Sun, 05 Oct 2014 06:43:14 -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 A2C0B1C392D; Sun, 5 Oct 2014 19:43:05 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 94A441A2760; Sun, 5 Oct 2014 19:43:05 +0900 (JST) In-Reply-To: <871tqneyvl.fsf@netris.org> 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:174987 Archived-At: Mark H Weaver writes: > I would like to change Guile's internal string representation to use a > generalization of UTF-8, as used by Emacs. There are two sticking > points that require more thought, however: > > * I'm concerned that there are security implications to supporting > the "raw byte" code points. There are greater security implications to using the full repertoire of Unicode (so-called confusables for a start). > However, I think this will not be a problem, because the > string<->bytevector conversion procedures could support two modes of > operation: one mode that supports these raw bytes, for use by emacs > and maybe some other purposes (e.g. dealing with POSIX file names), > and another mode that refuses to accept or produce invalid UTF-8, I'm not sure what you mean by "mode", but this behavior should be decided for each stream. IMO Python does this correctly (although its internal representation is fixed-width, not UTF-8). Specifically, raw bytes in I/O streams are treated as errors, and when encountered an error handler (which is specified stream-by-stream) decides how to treat them. Besides the in band "special character" representation, 'strict' (raise error) must be provided. Other handlers provided by Python include 'ignore' (drop from the stream), 'replace' (with a constant replacement character), 'backslashreplace' (replace with a hexadecimal representation such as "\x1F4A9") and 'xmlreplace' (replace with a character entity) handlers are provided. > Supporting property lists in Scheme raises difficult questions > such as: Difficult, really? > * What should the Scheme procedures 'string=?' and 'equal?' do when > comparing two strings with the equal character sequences but > unequal property lists? Ignore the property list. > * Should Scheme procedures such as 'substring', 'string-append', > 'string-upcase', etc, propagate the associated property list > data? Ignore the property list. > * Are there security implications to carrying around and possibly > propagating (via Scheme's "substring") extra information that is > effectively invisible to all procedures that have ever been > available in Scheme? Ignore the property list. > * What should Scheme's 'write' do when applied to a string that > includes a property list? ('write' is analogous to 'prin1'). Ignore the property list. There, that wasn't hard, was it? Scheme itself really needs only to provide a setter and a getter for the property list, and leave everything else up to Emacs (at first, anyway). If you're really worried about the security implications, provide a interpreter instance switch at invocation time (or even compile time) so that feature is only available in invocations that explicitly request it. This would default to on for Emacs processes, off for "vanilla" Guile, and other applications that embed special configurations of Guile can make their own choice. > Security concerns are more important for Guile than for Emacs, because > Guile is already being used to implement network programs such as web > servers, and generally aims to support a much wider range of > applications. Obviously, you don't know Emacs very well. Emacs is the Swiss Army knife of the software world. It is an operating system, a system library, an application development platform and an application. (We also walk dogs.) > What do you think? Do I worry too much [about nothing]? :) Listen to your Uncle David on this one. You should treat every instance of nil as a biohazard.