[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#6991: Please keep bytecode out of *Backtrace* buffers
From: |
Eli Zaretskii |
Subject: |
bug#6991: Please keep bytecode out of *Backtrace* buffers |
Date: |
Sat, 19 Nov 2016 20:34:50 +0200 |
> 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?
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".
- bug#6991: Please keep bytecode out of *Backtrace* buffers, npostavs, 2016/11/18
- bug#6991: Please keep bytecode out of *Backtrace* buffers, Drew Adams, 2016/11/18
- bug#6991: Please keep bytecode out of *Backtrace* buffers, Eli Zaretskii, 2016/11/19
- bug#6991: Please keep bytecode out of *Backtrace* buffers, npostavs, 2016/11/19
- bug#6991: Please keep bytecode out of *Backtrace* buffers, Eli Zaretskii, 2016/11/19
- bug#6991: Please keep bytecode out of *Backtrace* buffers, npostavs, 2016/11/19
- bug#6991: Please keep bytecode out of *Backtrace* buffers,
Eli Zaretskii <=
- bug#6991: Please keep bytecode out of *Backtrace* buffers, npostavs, 2016/11/19
- bug#6991: Please keep bytecode out of *Backtrace* buffers, Eli Zaretskii, 2016/11/20
- bug#6991: Please keep bytecode out of *Backtrace* buffers, Noam Postavsky, 2016/11/22
- bug#6991: Please keep bytecode out of *Backtrace* buffers, Eli Zaretskii, 2016/11/22
- bug#6991: Please keep bytecode out of *Backtrace* buffers, Noam Postavsky, 2016/11/22
- bug#6991: Please keep bytecode out of *Backtrace* buffers, Eli Zaretskii, 2016/11/23
- bug#6991: Please keep bytecode out of *Backtrace* buffers, npostavs, 2016/11/26
- bug#6991: Please keep bytecode out of *Backtrace* buffers, Stefan Monnier, 2016/11/26
- bug#6991: Please keep bytecode out of *Backtrace* buffers, Richard Stallman, 2016/11/26
- bug#6991: Please keep bytecode out of *Backtrace* buffers, Noam Postavsky, 2016/11/26