I've run across a problem in the XIM protocol as implemented by imTrX.c
(libX11)
and have a possible solution. I don't know who to send this to, so I'm
sending it
to both the i18n list and the xpert list
The function _XimXFilterWaitEvent() is called in the event filter (hence the
name :-)
A problem arises if _XimReadData() leaves data in the hold_data buffer. The
next
call to _XimXFilterWaitEvent() will end up calling XimReadData() which will
use
what's in the hold_data buffer instead of what was in the event, causing the
event
to get ignored. I have a case where this happens and the next event after
the one
being ignored is the 2nd half of a packet that got split up. Since it's got
no header,
it thinks the thing is really huge and things go Boom! (to use the technical
term)
The solution to this appears to be to modify _XimXFilterWaitEvent() as
follows...
Private Bool
_XimXFilterWaitEvent(d, w, ev, arg)
Display *d;
Window w;
XEvent *ev;
XPointer arg;
{
Xim im = (Xim)arg;
XSpecRec *spec = (XSpecRec *)im->private.proto.spec;
Bool ret;
spec->ev = (XPointer)ev;
ret = _XimFilterWaitEvent(im);
/*
* If ev is a pointer to a stack variable, there could be
* a coredump later on if the pointer is dereferenced.
* Therefore, reset to NULL to force reinitialization in
* _XimXRead().
*
* Keep in mind _XimXRead may be called again when the stack
* is very different.
*/
spec->ev = (XPointer)NULL;
/********* BEGIN MODIFICATION *******/
/*
* Don't leave stuff in hold_data while processing events or we'll
* end up skipping an event - This would be bad!
*/
while (im->private.proto.hold_data != NULL) {
ret = _XimFilterWaitEvent(im);
}
/********* END MODIFICATION *******/
return ret;
}
Ideally, it should check the ret value and return if there's an error,
-- Dave Williss
------
Meddle not in the affairs of dragons,
for you are crunchy and taste good with catsup
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
