From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Tue, 07 Oct 2014 11:15:05 -0400 Message-ID: <87mw97rjwm.fsf@yeeloong.lan> References: <54193A70.9020901@member.fsf.org> <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> <87h9zgarvp.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1412694997 25591 80.91.229.3 (7 Oct 2014 15:16:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Oct 2014 15:16:37 +0000 (UTC) Cc: Richard Stallman , dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca, Eli Zaretskii , stephen@xemacs.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 07 17:16:24 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 1XbWUw-00013p-WB for ged-emacs-devel@m.gmane.org; Tue, 07 Oct 2014 17:16:23 +0200 Original-Received: from localhost ([::1]:59376 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbWUw-0007v3-Bs for ged-emacs-devel@m.gmane.org; Tue, 07 Oct 2014 11:16:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51401) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbWUX-0007oV-9r for emacs-devel@gnu.org; Tue, 07 Oct 2014 11:16:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbWUR-00077q-De for emacs-devel@gnu.org; Tue, 07 Oct 2014 11:15:57 -0400 Original-Received: from world.peace.net ([96.39.62.75]:58254) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbWUK-00077O-KE; Tue, 07 Oct 2014 11:15:44 -0400 Original-Received: from c-24-62-95-23.hsd1.ma.comcast.net ([24.62.95.23] helo=yeeloong.lan) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1XbWU5-0004xc-Kf; Tue, 07 Oct 2014 11:15:29 -0400 In-Reply-To: <87h9zgarvp.fsf@fencepost.gnu.org> (David Kastrup's message of "Tue, 07 Oct 2014 16:14:50 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 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:175073 Archived-At: David Kastrup writes: > Richard Stallman writes: > >> [[[ To any NSA and FBI agents reading my email: please consider ]]] >> [[[ whether defending the US Constitution against all enemies, ]]] >> [[[ foreign or domestic, requires you to follow Snowden's example. ]]] >> >> For >> >> example, the ASCII quote (") can be represented as the single byte 0x22, >> >> the two byte sequence 0xC0 0xA2, etc. >> >> What does Emacs do now with a file that contains these "overlong" >> sequences? > > UTF-8 is defined as not containing "overlong" sequences, so Emacs > decodes them into two raw-byte indicating characters, one indicating > 0xC0, one indicating 0xA2. When encoding, it reassembles them into > 0xC0 0xA2. When editing a file, this is probably the right default behavior, although ideally it should warn the user. However, if the overlong sequence came from the network, and Emacs propagates it unchanged to internal subsystems[*] (e.g. via command-line arguments to subprocesses), that's not good. It exposes another program to invalid input -- a program that might not be designed for exposure to possible attacks via overlong encodings. [*] By "internal subsystem" I mean any part of the overall system that's not directly accessible to attacks. This includes subprocesses or daemons that are not accessible from the outside network. Mark