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

[Eli Zaretskii <eliz@gnu.org>]

> From: npostavs@users.sourceforge.net
> Cc: 6991@debbugs.gnu.org,  lekktu@gmail.com,  johnw@gnu.org,  monnier@iro.umontreal.ca,  larsi@gnus.org,  drew.adams@oracle.com
> Date: Sat, 19 Nov 2016 09:39:09 -0500
> 
> Eli Zaretskii <eliz@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.