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

[Eli Zaretskii <eliz@gnu.org>]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Tue, 22 Nov 2016 16:07:06 -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>
> 
> > 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?