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: 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: Sat, 19 Nov 2016 17:07:02 +0200

> From: npostavs <at> users.sourceforge.net
> Cc: 6991 <at> debbugs.gnu.org,  lekktu <at> gmail.com,  johnw <at> gnu.org,  monnier <at> iro.umontreal.ca,  larsi <at> gnus.org,  drew.adams <at> oracle.com
> Date: Sat, 19 Nov 2016 09:39:09 -0500
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> I would propose something like the below, which will cause the NUL byte
> >> to be rendered as \0 instead of ^@.  We could potentially do this with
> >> other control characters too, if they cause trouble too?
> >
> > Isn't the fact that copying text into the clipboard stops at the first
> > null character a Windows-specific issue?  And if it isn't Windows
> > specific, isn't it at least specific to selections?
> 
> It seems to be application specific.  When I copy to a Firefox text area
> on GNU/Linux I get a truncated result, but using xclip | od -c, I can
> see the NUL byte and following characters are there.

If this happens on both Windows and X, then both xselect.c and
w32select.c should "encode" null bytes.  Would that solve the problem?

> > Exactly.  But if we change print_object like you suggest, there's no
> > way of being sure the null bytes won't be mangled by some application
> > of a print function.
> 
> I'm not sure what you mean.

A literal string can be printed, and the result is generally the
string itself.  But with your suggestion, the null bytes will be
lossily converted to something else.

Previous Next

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