Yet another leak in Xlib

[Po Lu]

(Resending after subscribing as the list moderator seems to be
unresponsive.)

Doesn't this leak found by Valgrind from libX11 sound like a bug?  For
reference, here's how I'm calling XRegisterIMInstantiateCallback:

  XSetLocaleModifiers ("");
  XRegisterIMInstantiateCallback (compositor.display,
				  XrmGetDatabase (compositor.display),
				  (char *) compositor.resource_name,
				  (char *) compositor.app_name,
				  IMInstantiateCallback, NULL);

and XMODIFIERS is:

  @im=ibus

and the leak is:

==67186== 408 bytes in 1 blocks are definitely lost in loss record 272 of 344
==67186==    at 0x484A464: calloc (vg_replace_malloc.c:1328)
==67186==    by 0x490935F: _XimOpenIM (in /usr/lib64/libX11.so.6.4.0)
==67186==    by 0x490F386: _XimRegisterIMInstantiateCallback (in /usr/lib64/libX11.so.6.4.0)
==67186==    by 0x48FBDBD: XRegisterIMInstantiateCallback (in /usr/lib64/libX11.so.6.4.0)
==67186==    by 0x4456B5: tiInitTextInput (text_input.c:837)
==67186==    by 0x4079C5: dlMain (loader.c:205)
==67186==    by 0x4079F2: main (loader.c:214)

Thanks.

BTW, what about the keycode name leak that I found earlier? The fix
involving the resource name quark table seems like it would actually
work.

Also, there has been at least one recent change to Xlib that (if my
memory of the documentation is correct) goes against the documentation,
notably allowing the client to send XNSpotLocation when
XIMPreeditCallbacks is specified in the input method style:

  The XNSpotLocation argument specifies to the input method the
  coordinates of the spot to be used by an input method executing with
  XNInputStyle set to XIMPreeditPosition. When specified to any input
  method other than XIMPreeditPosition, this XIC value is ignored. <=====

  The x coordinate specifies the position where the next character would
  be inserted. The y coordinate is the position of the baseline used by
  the current text line in the focus window. The x and y coordinates are
  relative to the focus window, if it has been set; otherwise, they are
  relative to the client window. If neither the focus window nor the
  client window has been set, the results are undefined.

  The value of the argument is a pointer to a structure of type XPoint.

That is an incompatible change and should at least be documented.  I
remember having written input servers and clients in the past that
expect things to work the old way.