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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
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: bug#6991: Please keep bytecode out of *Backtrace* buffers
Date: Wed, 23 Nov 2016 18:05:37 +0200

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

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

Previous Next

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