From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#6991: Please keep bytecode out of *Backtrace* buffers Date: Wed, 23 Nov 2016 18:05:37 +0200 Message-ID: <8360ne6v1q.fsf@gnu.org> References: <8739tm9vzl.fsf@jidanni.org> <87vb5ct1lz.fsf@gnus.org> <2223f654-1e67-4a9a-a471-828fd4078410@default> <87fumokzbp.fsf@users.sourceforge.net> <83oa1bc3x2.fsf@gnu.org> <87d1hrlek2.fsf@users.sourceforge.net> <83eg27bjah.fsf@gnu.org> <87a8cvlcmk.fsf@users.sourceforge.net> <8360njb9o5.fsf@gnu.org> <877f7zksm0.fsf@users.sourceforge.net> <83oa1a9msk.fsf@gnu.org> <83vavf73ei.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1479917312 26775 195.159.176.226 (23 Nov 2016 16:08:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 23 Nov 2016 16:08:32 +0000 (UTC) Cc: lekktu@gmail.com, johnw@gnu.org, monnier@iro.umontreal.ca, 6991@debbugs.gnu.org, larsi@gnus.org To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 23 17:08:25 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c9a5x-0006bU-J1 for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Nov 2016 17:08:25 +0100 Original-Received: from localhost ([::1]:34708 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9a61-0003AN-3T for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Nov 2016 11:08:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59632) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9a4i-0002Qn-2z for bug-gnu-emacs@gnu.org; Wed, 23 Nov 2016 11:07:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c9a4c-0002Fm-2W for bug-gnu-emacs@gnu.org; Wed, 23 Nov 2016 11:07:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52276) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c9a4b-0002Ey-SM for bug-gnu-emacs@gnu.org; Wed, 23 Nov 2016 11:07:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c9a4b-000621-KC for bug-gnu-emacs@gnu.org; Wed, 23 Nov 2016 11:07:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Nov 2016 16:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6991 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6991-submit@debbugs.gnu.org id=B6991.147991720623161 (code B ref 6991); Wed, 23 Nov 2016 16:07:01 +0000 Original-Received: (at 6991) by debbugs.gnu.org; 23 Nov 2016 16:06:46 +0000 Original-Received: from localhost ([127.0.0.1]:39442 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c9a4I-00061S-HW for submit@debbugs.gnu.org; Wed, 23 Nov 2016 11:06:45 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:39978) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c9a4E-00061D-2a for 6991@debbugs.gnu.org; Wed, 23 Nov 2016 11:06:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c9a45-0001bA-BK for 6991@debbugs.gnu.org; Wed, 23 Nov 2016 11:06:32 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56622) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9a3V-00011n-6M; Wed, 23 Nov 2016 11:05:53 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2497 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c9a3U-0003Zo-99; Wed, 23 Nov 2016 11:05:52 -0500 In-reply-to: (message from Noam Postavsky on Tue, 22 Nov 2016 16:07:06 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:126015 Archived-At: > From: Noam Postavsky > Date: Tue, 22 Nov 2016 16:07:06 -0500 > Cc: 6991@debbugs.gnu.org, Juanma Barranquero , John Wiegley , > Stefan Monnier , Lars Magne Ingebrigtsen , > Drew Adams > > > I'm confused: which problem the above is supposed to fix? Are we > > still talking about putting null bytes in selections, or are we > > talking about something else? > > The original bug report is about copying backtraces containing byte > code to other applications (e.g., web browser, mail client, etc). The > byte code in backtraces is currently printed with several characters > backslash escaped (newline, formfeed, backslash, double quote, and > characters higher than 0x80). I propose to extend this escaping to > null bytes as well. That will (somewhat indirectly) solve the problem > of copying backtraces to other applications, without lossyness (i.e., > (equal (read (print str)) str) remains true). It won't solve the > problem of copying arbitrary text containing null bytes to other > applications, it only avoids the most common case of the user needing > to copy text containing null bytes. I'm not necessarily opposed, but I never had any problems with binary nulls, except when copying to clipboard. > So in addition to that, your proposal to escape null bytes in xselect > and w32select would still be needed to cover the general case. The > drawback to replacing nulls in the {x,w32}select code is that the > conversion is lossy, and there is a slightly increased chance of the > user not noticing there was lossy conversion (relative to the current > lossy "conversion" of truncating the string). Yes, it's lossy, but what other alternative do we have, except losing much more?