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

From: Eli Zaretskii <[email-masked]>
Date: Wed, 23 Nov 2016 18:05:37 +0200

> From: Noam Postavsky <[email-masked]>
> Date: Tue, 22 Nov 2016 16:07:06 -0500
> Cc: [email-masked], Juanma Barranquero <[email-masked]>, John Wiegley <[email-masked]>, 
> 	Stefan Monnier <[email-masked]>, Lars Magne Ingebrigtsen <[email-masked]>, 
> 	Drew Adams <[email-masked]>
> 
> > 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?