Patch: fix cut & past problem on 64 bit platforms

[Mike FABIAN]

Takashi Iwai <tiwai at suse.de> さんは書きました:

> At Sat, 17 Feb 2007 14:09:51 +0900,
> Stephen J. Turnbull wrote:
>> 
>> Mike FABIAN writes:
>> 
>>  > Patch by Takashi IWAI and me.
>> 
>> Thanks for the patch!
>> 
>>  > For details please have a look at
>>  > 
>>  > http://bugzilla.novell.com/show_bug.cgi?id=244613
>> 
>> (1) As I understand it the crash is presumably caused by a buffer
>> overrun overwriting the stack, not in the codec trying to decode a
>> corrupt (truncated) selection string, right?  Ie, the problem leading
>> to a crash has been fixed here, it's not something in the codec that
>> is masked by giving it uncorrupt data?
>  
> Yes, it was just a mistake in my patches.  The last patch in the above
> is correct and doesn't lead to crashes.
>
> I misunderstood X*Property() API as if they return the real byte
> length.  The API returns, however, the size of bytes in the assumption
> of data witdth = 32bit (as format = 32).

>> (2) Now, this looks like a bug in the 64-bit X libraries to me.  What
>> happens if it gets fixed?
>
> It's no implementation bug but a brain-dead API definition.

Yes, it really is a very weird design but it seems to be designed on
purpose like this.

If that API would ever change it would of course cause serious
problems again with all programs using XGetWindowProperty() on 64bit,
therefore we will have to live with that strange design forever.

If one calls (get-selection-internal 'PRIMARY 'TARGETS) while some
string is selected in rxvt-unicode, The function XGetWindowProperty is
called twice in XEmacs. The first call is to find out how many bytes
need to be read. XGetWindowProperty() returns "24" in the variable
"bytes_after_return". XEmacs then allocates 24+1 bytes.  But that was
not enough because in reality the property array which is returned has
"48" bytes, it consists of six 4 byte values which are padded with 4
extra zeros after each value.  It is unbelievably strange but it
really is designed like that.  When Takashi found that the wrong usage
of the function XGetWindowProperty causes the problem, I remembered
that I had seen the same problem in some other program years before.
How XGetWindowProperty() works on 64 bit is so strange, it is no
wonder that many programs don't do it right on 64bit.  GNU Emacs 21
apparently has the same problem (I have not yet checked in detail and
I have not yet checked whether the problem remains for GNU Emacs 22,
but the behaviour of (x-get-selection-internal 'PRIMARY 'TARGETS) on
GNU Emacs shows the same bug we just fixed for XEmacs).

-- 
Mike FABIAN   <mfabian at suse.de>   http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
I � Unicode