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 10:20:51 -0500
> 
> >> > 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?
> 
> When printing a string literal, a null byte can be encoded as "\0", but
> in general, when copying an arbitrary piece of text this encoding might
> not necessarily be correct.

Not sure what you have in mind.  Can you show an example of when it's
not correct?

At least on MS-Windows, we only support text selections, so doing so
in w32select.c should be TRT, because clipboard text cannot include
null bytes on Windows, AFAIK.  I also think it's TRT elsewhere, when
the selection value is some kind of text.

> > 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.
> 
> I don't think it's lossy.

It's lossy because you can never know whether it came from a null byte
or from a literal ASCII text "\0".