bug#6991: Please keep bytecode out of *Backtrace* buffers

[Noam Postavsky <npostavs@users.sourceforge.net>]

On Tue, Nov 22, 2016 at 1:52 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Tue, 22 Nov 2016 13:07:13 -0500
>> Cc: 6991@debbugs.gnu.org, Juanma Barranquero <lekktu@gmail.com>, John Wiegley <johnw@gnu.org>,
>>       Stefan Monnier <monnier@iro.umontreal.ca>, Lars Magne Ingebrigtsen <larsi@gnus.org>,
>>       Drew Adams <drew.adams@oracle.com>
>>
>> On Sun, Nov 20, 2016 at 10:46 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >
>> > 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.
>>
>> Does the fact that this replacement would only happen when
>> `print-escape-nonascii' is non-nil help at all? And the fact that this
>> same function already escapes newline, formfeed, and every character
>> larger than 0x80 (all of which Emacs can handle in strings too)?
>>
>> Can we have both solutions? The selection fix is lossy, so avoiding
>> the need for it where possible seems like a good thing to me.
>
> 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.

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).