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

Previous Next

Full log

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

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
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 10:20:51 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

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

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.

Previous Next

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