GNU bug report logs - #6991
Please keep bytecode out of *Backtrace* buffers

Previous Next

Full log

Message #154 received at 6991 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, johnw <at> gnu.org, monnier <at> iro.umontreal.ca,
 6991 <at> debbugs.gnu.org, larsi <at> gnus.org, drew.adams <at> oracle.com
Subject: Re: bug#6991: Please keep bytecode out of *Backtrace* buffers
Date: Sat, 26 Nov 2016 12:18:00 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
>> Date: Tue, 22 Nov 2016 16:07:06 -0500
>> Cc: 6991 <at> debbugs.gnu.org, Juanma Barranquero <lekktu <at> gmail.com>, John Wiegley <johnw <at> gnu.org>, 
>> 	Stefan Monnier <monnier <at> iro.umontreal.ca>, Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 
>> 	Drew Adams <drew.adams <at> 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.

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.