GNU bug report logs -
#6991
Please keep bytecode out of *Backtrace* buffers
Previous Next
Reported by: jidanni <at> jidanni.org
Date: Tue, 7 Sep 2010 01:34:01 UTC
Severity: wishlist
Tags: fixed, notabug
Merged with 15789
Found in version 24.3.50
Fixed in version 26.1
Done: npostavs <at> users.sourceforge.net
Bug is archived. No further changes may be made.
Full log
Message #124 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> 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 09:39:09 -0500
>
> Eli Zaretskii <eliz <at> 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?
> > 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.
This bug report was last modified 7 years and 254 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.