GNU bug report logs - #6991
Please keep bytecode out of *Backtrace* buffers

Previous Next

Full log

Message #133 received at 6991 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: lekktu <at> gmail.com, johnw <at> gnu.org, monnier <at> iro.umontreal.ca,
 6991 <at> debbugs.gnu.org, larsi <at> gnus.org, drew.adams <at> oracle.com
Subject: Re: bug#6991: Please keep bytecode out of *Backtrace* buffers
Date: Sat, 19 Nov 2016 20:34:50 +0200

> From: npostavs <at> users.sourceforge.net
> Cc: 6991 <at> debbugs.gnu.org,  lekktu <at> gmail.com,  johnw <at> gnu.org,  monnier <at> iro.umontreal.ca,  larsi <at> gnus.org,  drew.adams <at> 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".

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.