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: Sun, 20 Nov 2016 17:46:35 +0200 Message-ID: <83oa1a9msk.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1479656895 22528 195.159.176.226 (20 Nov 2016 15:48:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 20 Nov 2016 15:48:15 +0000 (UTC) Cc: lekktu@gmail.com, johnw@gnu.org, monnier@iro.umontreal.ca, 6991@debbugs.gnu.org, larsi@gnus.org To: npostavs@users.sourceforge.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 20 16:48:11 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 1c8ULi-00050Q-Oj for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Nov 2016 16:48:10 +0100 Original-Received: from localhost ([::1]:45321 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8ULm-0002Wg-BS for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Nov 2016 10:48:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40150) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8ULe-0002Ve-Hr for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2016 10:48:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c8ULa-0005Hz-A8 for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2016 10:48:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49094) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c8ULa-0005Ht-6d for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2016 10:48:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c8ULZ-00069U-Tk for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2016 10:48: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: Sun, 20 Nov 2016 15:48: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.147965684223591 (code B ref 6991); Sun, 20 Nov 2016 15:48:01 +0000 Original-Received: (at 6991) by debbugs.gnu.org; 20 Nov 2016 15:47:22 +0000 Original-Received: from localhost ([127.0.0.1]:36260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c8UKw-00068Q-6a for submit@debbugs.gnu.org; Sun, 20 Nov 2016 10:47:22 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:49110) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c8UKu-00068A-JG for 6991@debbugs.gnu.org; Sun, 20 Nov 2016 10:47:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c8UKl-0005CG-2k for 6991@debbugs.gnu.org; Sun, 20 Nov 2016 10:47:15 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60854) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8UK3-00055G-TR; Sun, 20 Nov 2016 10:46:27 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1653 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c8UK2-00024D-UZ; Sun, 20 Nov 2016 10:46:27 -0500 In-reply-to: <877f7zksm0.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net) 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:125900 Archived-At: > From: npostavs@users.sourceforge.net > Cc: 6991@debbugs.gnu.org, lekktu@gmail.com, johnw@gnu.org, monnier@iro.umontreal.ca, larsi@gnus.org, drew.adams@oracle.com > Date: Sat, 19 Nov 2016 17:33:11 -0500 > > >> > If this happens on both Windows and X, then both xselect.c and > >> > w32select.c should "encode" null bytes. Would that solve the problem? > >> > >> When printing a string literal, a null byte can be encoded as "\0", but > >> in general, when copying an arbitrary piece of text this encoding might > >> not necessarily be correct. > > > > Not sure what you have in mind. Can you show an example of when it's > > not correct? > > I can't really think of a practical example, but it seems that the same > objection you raised below applies: how would you know whether what was > copied had the literal ASCII text "\0" or a null byte? We can't. But since null bytes cannot be put into the Windows clipboard, we have only 2 possible ways of action: either replace the null bytes with something else, or lose everything past the first null bytes (which is the current behavior, against which this bug report was submitted). So if we want to solve this problem, what else can we do except use some lossy conversion? > > At least on MS-Windows, we only support text selections, so doing so > > in w32select.c should be TRT, because clipboard text cannot include > > null bytes on Windows, AFAIK. I also think it's TRT elsewhere, when > > the selection value is some kind of text. > > It doesn't really feel like the Right Thing to me, there's no particular > reason to choose "\0" for this, e.g., why not use "^@" (an ASCII caret > followed by at sign)? If you thought I was arguing against ^@ and for \0, then this is a misunderstanding: I don't really care one way of the other. I was saying that we must do _something_ to replace those null bytes, if we want the text beyond the first one be seen in the application into which you paste. > > It's lossy because you can never know whether it came from a null byte > > or from a literal ASCII text "\0". > > It's already the case that ASCII text "\0" is printed as "\\0", without > my patch: > > (print (string 0 ?\\ ?0) (current-buffer)) > > "^@\\0" ;; I replaced the null byte with "^@" to avoid trouble with > ;; email clients > > With my patch, ^@ is replaced with \0: > > (print (string 0 ?\\ ?0) (current-buffer)) > > "\0\\0" It just doesn't feel right to me to fix a problem that is specific to selections in a general-purpose low-level facility for printing strings. Emacs can handle null bytes in strings very well, so I see no need to change the print functions.