bug#20906: 25.0.50;

[Eli Zaretskii]

> From: Mike FABIAN <mfabian@redhat.com>
> Cc: schwab@suse.de, 20906@debbugs.gnu.org
> Date: Tue, 06 Oct 2015 08:30:11 +0200
> 
> Eli Zaretskii <eliz@gnu.org> さんはかきました:
> 
> >> From: Mike FABIAN <mfabian@redhat.com>
> >> Cc: Andreas Schwab <schwab@suse.de>, 20906@debbugs.gnu.org
> >> Date: Mon, 05 Oct 2015 17:08:30 +0200
> >> 
> >> With tracing turned on, I see something like this:
> >> 
> >> Breakpoint 1, x_get_window_property_as_lisp_data (dpyinfo=0x16d9070,
> >>     window=119537791, property=602, target_type=8256, selection_atom=1)
> >>     at xselect.c:1469                                                  
> >> Continuing.
> >> 9577: Reading selection data
> >> 9577: Read 18 bytes from property _EMACS_TMP_
> >> 9577:   Delete property _EMACS_TMP_
> >
> > Thanks.  Do you see the same in v24.5?
> 
> In v24.5 I see at the same point, i.e. when breaking 
> at x_get_window_property_as_lisp_data and then
> single stepping until after x_get_window_property:
> 
>     (gdb) n
>     23750: Reading selection data
>     23750: Read 6 bytes from property _EMACS_TMP_
>     (gdb) p   data
>     $1 = (unsigned char *) 0x145c300 "終了"
>     (gdb) p   property
>     $2 = 602
>     (gdb) c
>     Continuing.
>     23750:   Delete property _EMACS_TMP_
> 
> Here the Japanese text I pasted ("終了") appears just like that
> in gdb (running in a terminal in UTF-8 mode, i.e. this is
> UTF-8 encoded text).

If the data we receive is different, I guess the only explanation
could be that we request it in some different way?