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: Tue, 07 Oct 2014 02:43:02 +0900 Message-ID: <87ppe5rt5l.fsf@uwakimon.sk.tsukuba.ac.jp> References: <54193A70.9020901@member.fsf.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> <87d2a54t1m.fsf@yeeloong.lan> <83lhotme1e.fsf@gnu.org> <871tql17uw.fsf@yeeloong.lan> <838uktm9gw.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 1412617432 10697 80.91.229.3 (6 Oct 2014 17:43:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Oct 2014 17:43:52 +0000 (UTC) Cc: dak@gnu.org, rms@gnu.org, Mark H Weaver , dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 06 19:43:45 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 1XbCJz-0000Lv-Oq for ged-emacs-devel@m.gmane.org; Mon, 06 Oct 2014 19:43:43 +0200 Original-Received: from localhost ([::1]:53410 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbCJz-0002yd-Cx for ged-emacs-devel@m.gmane.org; Mon, 06 Oct 2014 13:43:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37631) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbCJh-0002yP-DC for emacs-devel@gnu.org; Mon, 06 Oct 2014 13:43:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbCJb-0003vo-5T for emacs-devel@gnu.org; Mon, 06 Oct 2014 13:43:25 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:59193) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbCJN-0003a6-IT; Mon, 06 Oct 2014 13:43:05 -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 24FF31C3904; Tue, 7 Oct 2014 02:43:03 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 132F81A2888; Tue, 7 Oct 2014 02:43:03 +0900 (JST) In-Reply-To: <838uktm9gw.fsf@gnu.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:175030 Archived-At: Eli Zaretskii writes: > > From: Mark H Weaver > > It doesn't matter how these raw bytes are encoded internally. No > > matter what mechanism we use to accomplish it, propagating > > invalid byte sequences by default is bad security policy. > > How can we be responsible for byte streams that originated outside? By taking responsibility for them. ;-) > That's the responsibility of the source. And if there is a consumer, > then it is their responsibility not to trip upon such bytes. Not in a security context. In a security context, you want defense in depth: all separately developed components cooperate in covering up each others' bugs by handling input carefully and refusing to transmit broken output unless that is explicitly requested by the consumer (and you trust it to know what it's doing when it says, "don't worry, I can handle anything"!) > But how can you refuse to copy such bytes when you are just a pipe > that is expected not to change anything it wasn't toild to? By signaling an error and terminating. That's what a conformant Unicode process does. Note that the standard doesn't say you have to throw away state and give up entirely. It just says that if you do try to continue, you're not conforming any more. > > The Unicode standard requires that all UTF-8 codecs refuse to > > accept, produce, or propagate invalid byte sequences, including > > the troublesome overlong encodings. Again, what the Unicode standard says is that a codec that does any of those things may not call itself conformant. It doesn't say anything about nonconformant codecs -- which include all non-Unicode codecs, of course. So we already know that Emacs is going to be nonconformant in some use cases. However, it should be aware of the fact when it is not conforming to applicable standards. > So just passing a string unaltered through a Guile program would > change that string? If it is a stream of bytes which is alleged to conform to some standard but in fact does not, a program should (in general IMO, and by the Unicode standard if it claims Unicode conformance) signal an error and stop. If the program wishes to pick up where it left off in nonconformant mode and continue processing, that's fine (but it isn't conformant any more). In other words, "correcting" the string would be a nonconformant behavior. But this must be an explicit decision by the program (and it mustn't do that if the user wants conformance). Mark is absolutely correct that the Guile system should not default to non-conformance, and I don't think Emacs based on Guile should either, but that's up to the Emacs community to decide, of course.