Re: incompatible change in XIMPreeditCallbacks
On 10/2/22 17:44, Po Lu wrote: Alan Coopersmith writes: Unfortunately, there is no one left reviewing Xlib patches who knows how input methods work or what might be a breaking change, or who could write documentation of such changes. We'd love for someone to step up and take on such work. How about this? diff --git a/specs/libX11/CH13.xml b/specs/libX11/CH13.xml index 5ca59790..6be4f1c2 100644 --- a/specs/libX11/CH13.xml +++ b/specs/libX11/CH13.xml @@ -8045,7 +8045,11 @@ set to XIMPreeditPosition. When specified to any input method other than XIMPreeditPosition, -this XIC value is ignored. +this XIC value is ignored. Some Xlib implementations +will allow this to be set when +XNInputStyle is set to +XIMPreeditCallbacks. Behavior in that case is +implementation defined. I didn't see any feedback, nor a merge request from you, so I've included it in: https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/166 Thanks, -alan-
Re: AW: Yet another leak in Xlib
Done: https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/166 -alan- On 10/18/22 02:57, Walter Harms wrote: will sombody close the hole in the documentation ? Von: xorg-devel im Auftrag von Po Lu Gesendet: Dienstag, 4. Oktober 2022 04:38 An: Thomas Dickey Cc: xorg-devel@lists.x.org Betreff: Re: Yet another leak in Xlib Thomas Dickey writes: looks okay reading the library code (src/xlibi18n/XDefaultIMIF.c, _CloseIM). xterm doesn't free that 'xim' value (and the XCloseIM manual page doesn't say who's responsible for that -- though it's possible that some other application developer read the library source code and is freeing it). XCloseIM (in IMWrap.c) frees the XIM value itself after calling close to deinitialize the input method. So I think the patch should be fine, and I've been running it for a while with no ill effect. Could it be installed? Thanks. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Re: Fwd: XInitThreads in library constructor breaks Motif!
On 11/3/22 04:46, Po Lu wrote: Matthieu Herrb writes: My french input method has eaten the URL. here the unmangled one: https://marc.info/?l=openbsd-tech=166742060513284=2 My crystal ball says it's probably that before XInitThreads was called, pthread stubs somehow found their way into the executable image. If you link the crashing program with -lpthread, does the crash magically go away? If that's the case, then this should already be solved in git for 1.8.2: https://gitlab.freedesktop.org/xorg/lib/libx11/-/commit/1f8fd7ff1cf688e https://gitlab.freedesktop.org/xorg/lib/libx11/-/commit/701e9e9afb88bdc -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Re: Fwd: XInitThreads in library constructor breaks Motif!
Matthieu Herrb writes: > My french input method has eaten the URL. here the unmangled one: > > https://marc.info/?l=openbsd-tech=166742060513284=2 My crystal ball says it's probably that before XInitThreads was called, pthread stubs somehow found their way into the executable image. If you link the crashing program with -lpthread, does the crash magically go away?
Re: Fwd: XInitThreads in library constructor breaks Motif!
On Wed, Nov 02, 2022 at 10:13:02PM +0100, Matthieu Herrb wrote: > On Wed, Nov 02, 2022 at 11:29:19AM -0700, Alan Coopersmith wrote: > > On 11/2/22 07:53, Adam Jackson wrote: > > > I missed that! My apologies. I've merged the reentrancy patch, we should > > > probably push out another release shortly. > > > > Now that this change is in, I'll wait a few days for any more testing to > > be reported and then probably cut a 1.8.2 release next week. > > > > https://marc.infœ?l=openbsd-tech=166742060513284=2 My french input method has eaten the URL. here the unmangled one: https://marc.info/?l=openbsd-tech=166742060513284=2 > doesn't look too good. unfortunatly no time to try to see if I can > reproduce this before next week. > > -- > Matthieu Herrb -- Matthieu Herrb
