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

[npostavs]

Eli Zaretskii <eliz@gnu.org> writes:

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

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.

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

I don't think it's lossy.  Furthermore, newlines and form feeds are
already being converted to "\n" and "\f", respectively.  Bytes higher
than 0x80 are also converted to octal escapes.