From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: npostavs@users.sourceforge.net Newsgroups: gmane.emacs.bugs Subject: bug#6991: Please keep bytecode out of *Backtrace* buffers Date: Sat, 19 Nov 2016 17:33:11 -0500 Message-ID: <877f7zksm0.fsf@users.sourceforge.net> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1479594799 6219 195.159.176.226 (19 Nov 2016 22:33:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 19 Nov 2016 22:33:19 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: lekktu@gmail.com, johnw@gnu.org, monnier@iro.umontreal.ca, 6991@debbugs.gnu.org, larsi@gnus.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 19 23:33:12 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 1c8EC7-0000T6-Oo for geb-bug-gnu-emacs@m.gmane.org; Sat, 19 Nov 2016 23:33:11 +0100 Original-Received: from localhost ([::1]:42976 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8ECB-0005WA-4z for geb-bug-gnu-emacs@m.gmane.org; Sat, 19 Nov 2016 17:33:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53148) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8EC1-0005Vo-BM for bug-gnu-emacs@gnu.org; Sat, 19 Nov 2016 17:33:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c8EBx-0005b3-Tr for bug-gnu-emacs@gnu.org; Sat, 19 Nov 2016 17:33:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48207) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c8EBx-0005az-QV for bug-gnu-emacs@gnu.org; Sat, 19 Nov 2016 17:33:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c8EBx-0008Gi-IP for bug-gnu-emacs@gnu.org; Sat, 19 Nov 2016 17:33:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: npostavs@users.sourceforge.net Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Nov 2016 22:33: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.147959475431740 (code B ref 6991); Sat, 19 Nov 2016 22:33:01 +0000 Original-Received: (at 6991) by debbugs.gnu.org; 19 Nov 2016 22:32:34 +0000 Original-Received: from localhost ([127.0.0.1]:35373 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c8EBT-0008Fo-2S for submit@debbugs.gnu.org; Sat, 19 Nov 2016 17:32:34 -0500 Original-Received: from mail-io0-f180.google.com ([209.85.223.180]:36550) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c8EBO-0008FW-Uz for 6991@debbugs.gnu.org; Sat, 19 Nov 2016 17:32:30 -0500 Original-Received: by mail-io0-f180.google.com with SMTP id x94so12774803ioi.3 for <6991@debbugs.gnu.org>; Sat, 19 Nov 2016 14:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=Ua2MrWF0iOtyRbhIwK0AXkMLT11wMdLHZBvB9yt0Uow=; b=sVpbEQY5xNTLWB+fQ8CXm0JnPJvT3RAaoLk0FSP8IuyBtCg3Osgjbtk3ish4yWH+Iq zGw96vQ0JctJUShbMbHujQlWWk7ugS638pFloCvmNVf5EwcKDIxIXttFO9iJ1nGYRhwq 337EJfo+CBUuu2nwUlK+M0xTz52HNgfZYAQuSGwVHv0HQdygGN2RmZm+8T8lETxhmklR rIdaz36dRBLyr94/Q9smt2NwHBq74GyFg0TeMSpuVLDix4HKwt3Ev1vhpcPhbUT4afGC IoqwacWuxQ3hhxzduDOArWM+AeKYd9zFWeg4qEXidyjzEQgTiTm7JiQ/Ga170uSppLC9 v1zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=Ua2MrWF0iOtyRbhIwK0AXkMLT11wMdLHZBvB9yt0Uow=; b=fxRvZNc681XDua6pmTm9w/Bii0bbwH5XCdAvO7nK+OomCunjk77pMrs6Sd7cwVLx6G ed77z8X+J4mSESwV1fi5UT/6NHFfI12PoygcXWWI8HsHZw/nXm7TRvXX2zgzfHLWHfcd IuKx9N0plOgfG/Z7I7I2RhFcmFZVfcGIjQKpU22PSK8y4n27d7s5wQLR8T9moqrZ5ypl 7glfNjIX5st7P/uzgZM+K1hRkvZaf7MUl4Yf8+ndGeUu/MAep+eJ5XciJjBcm5vM8wQR U/Xb5B6fS7poqkEVDiB9DGbxYc5Em7xUb60npzNI/2awGSodIu8OCcr21e5XDPocrtl+ FR8Q== X-Gm-Message-State: AKaTC00IKKD6Y5VeaIhm6yGi1s+fDG7YNCp2pJD50JBriOt6aa4sycTWZyKGI/sxjhvy0Q== X-Received: by 10.107.34.8 with SMTP id i8mr5089594ioi.132.1479594741148; Sat, 19 Nov 2016 14:32:21 -0800 (PST) Original-Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id a71sm3487918itc.11.2016.11.19.14.32.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 19 Nov 2016 14:32:20 -0800 (PST) In-Reply-To: <8360njb9o5.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 19 Nov 2016 20:34:50 +0200") 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:125885 Archived-At: Eli Zaretskii writes: >> 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 10:20:51 -0500 >> >> >> > Isn't the fact that copying text into the clipboard stops at the first >> >> > null character a Windows-specific issue? And if it isn't Windows >> >> > specific, isn't it at least specific to selections? >> >> >> >> It seems to be application specific. When I copy to a Firefox text area >> >> on GNU/Linux I get a truncated result, but using xclip | od -c, I can >> >> see the NUL byte and following characters are there. >> > >> > 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? > > 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)? In the case of printing a string literal, it's established that a backslash means escaping within the double quotes. > >> > A literal string can be printed, and the result is generally the >> > string itself. But with your suggestion, the null bytes will be >> > lossily converted to something else. >> >> I don't think it's lossy. > > 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"