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

[Eli Zaretskii]

> 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 17:33:11 -0500
> 
> >> > 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?

We can't.  But since null bytes cannot be put into the Windows
clipboard, we have only 2 possible ways of action: either replace the
null bytes with something else, or lose everything past the first null
bytes (which is the current behavior, against which this bug report
was submitted).  So if we want to solve this problem, what else can we
do except use some lossy conversion?

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

If you thought I was arguing against ^@ and for \0, then this is a
misunderstanding: I don't really care one way of the other.  I was
saying that we must do _something_ to replace those null bytes, if we
want the text beyond the first one be seen in the application into
which you paste.

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

It just doesn't feel right to me to fix a problem that is specific to
selections in a general-purpose low-level facility for printing
strings.  Emacs can handle null bytes in strings very well, so I see
no need to change the print functions.