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

[npostavs@users.sourceforge.net]

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

I can't really think of a practical example, but it seems that the same
objection you raised below applies: how would you know whether what was
copied had the literal ASCII text "\0" or a null byte?

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

It doesn't really feel like the Right Thing to me, there's no particular
reason to choose "\0" for this, e.g., why not use "^@" (an ASCII caret
followed by at sign)?  In the case of printing a string literal, it's
established that a backslash means escaping within the double quotes.

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

It's already the case that ASCII text "\0" is printed as "\\0", without
my patch:

(print (string 0 ?\\ ?0) (current-buffer))

"^@\\0" ;; I replaced the null byte with "^@" to avoid trouble with
        ;; email clients

With my patch, ^@ is replaced with \0:

(print (string 0 ?\\ ?0) (current-buffer))

"\0\\0"