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

From: [email-masked]
Date: Sat, 26 Nov 2016 12:18:00 -0500

Eli Zaretskii <[email-masked]> writes:

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

I've never needed to copy binary nulls except when a backtrace had one.

>
>> 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?

Yes, there's no perfect solution.  That's why I prefer to solve just the
immediate problem by extending the escaping in `print' to cover null
bytes.  And this will keep working if, for example, we make the general
case of copying null bytes to clipboard use a customizable replacement.