The documentation for this family of functions very clearly says not to
call into xlib in your predicate function, but historically single
threaded apps could get away with it just fine, and now that we've
forced thread-safety on the world such apps will now deadlock instead.
That's not an acceptable regression even if the app is technically
broken. This has been reported with XFCE and FVWM, and Motif's
cut-and-paste code has the same bug by inspection, so this does need to
be addressed.
This change nerfs LockDisplay/UnlockDisplay while inside the critical
bit of an IfEvent function. This is still safe in the sense that the
display remains locked and no other thread should be able to change it
from under us, but the loop that scans the event queue might not be
robust against it being modified as a side effect of protocol emitted by
the predicate callback. But that's not new, non-XInitThreads'd xlib
would have the same caveat.
Closes: xorg/lib/libx11#157
Several other `<Multi_key> <asciicircum> <symbol>` sequences
produce the superscript equivalent of the given symbol. So,
let `<Multi_key> <asciicircum> <minus>` do the same.
Also, add two other sequences for producing a plain macron,
to compensate a bit the loss of the above sequence.
Additionally, make `<Multi_key> <underscore> <minus>` produce
a subscript minus, for consistency.
This fixes issue #165.
Requested-by: J. McWilliams
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Serbian used sr_YU (Yugoslavia) code in the past.
Then it was succeeded by sr_CS (Serbia and Montenegro).
Finally, it was split into sr_RS (Serbia) and sr_ME (Montenegro).
da95ecbbdc
introduced the modern sr_RS and sr_ME codes.
Next, 4076189869
added the Serbian compose table but only for the legacy sr_CS entry.
5cd60398b7
removed the legacy sr_CS entry, the only one pointing to the correct compose file.
It also renamed the file to sr_RS, but did not update the compose mapping.
Let’s point all Serbian locales to the Compose file again.
Two years ago, commit b126bfd7fe allowed using also a lowercase `u`
wherever an uppercase `U` was used to represent a breve. But the
commit should have limited itself to only the prefixed uses of `U`,
as that is how most letters with a breve are composed.
Also, group the two compose sequences with an uppercase post-fixed `U`
together with the corresponding other post-fixed sequences.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Avoid conflicts when libX11 calls libxcb and gets its pthread functions
overriding our ancient stubs.
v2: Keep linking with real threads libraries when thread safety
constructor is enabled.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Analysis:
_XimRegisterIMInstantiateCallback() opens an XIM and closes it using
the internal function pointers, but the internal close function does
not free the pointer to the XIM (this would be done in XCloseIM()).
Report/patch:
Date: Mon, 03 Oct 2022 18:47:32 +0800
From: Po Lu <luangruo@yahoo.com>
To: xorg-devel@lists.x.org
Subject: Re: Yet another leak in Xlib
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
Signed-off-by: Thomas E. Dickey <dickey@invisible-island.net>
Only really makes a difference if pthreads is not in libc.
Fixes: #162
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The code here that made indexes greater than 3 refer to XKB symbol
groups had an off-by-one error, so it would always leave out the symbol
that should have been at index 4. Rewrite the code to fix this and
simplify the logic a bit.
Signed-off-by: Adam Sampson <ats@offog.org>
/work/xorg/lib/libX11/src/XlibInt.c:1968: multiple definition of `_Xdebug_p'; .libs/globals.o:globals.c:(.bss+0xc): first defined here
Avoid redundant definition of _Xdebug_p in globals.c (which is under the
influence of _Xdebug being #defined to _Xdebug_p.
This appears to be an ancient hack to work around data exports resolving
to the address of the import stub, not the import. (See [1]).
(This is probably no longer needed or can be done in a better way, as
per the discussion under --enable-auto-import in the ld manpage.)
[1] https://cygwin.com/pipermail/cygwin-xfree/2001-May/004606.html
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
These sequences each produce two code points: the E-with-dot-above and
a combining macron. The XIM input method is required for this to work.
(Also add a missing comment for a Unicode block.)
This fixes issue #54.
Requested-by: Arns Udovīčė
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Typing a compose sequence requires some care -- surely the user is able
to either keep holding the Shift key or not touch it at all while typing
the sequence. Also, compose sequences are not an infinite resource AND
take up space and time -- defining redundant ones is a waste.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
This allows the user to type the symbols for the five number systems.
This fixes the reasonable part of issue #159.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Fourteen years ago, commit 7302984642 added some four hundred compose
sequences for the benefit of the French Bépo layout. But among these
four hundred there are several that use symbols that are not available
in the Bépo layout and are thus impossible to type. Some of the used
symbols, like Ahook, Ehook and Ohook, are not even present in *any*
layout, making these sequences a dead weight in the Compose file.
The Amacron and Omacron are available only in the Latvian, Hawaiian,
and Maori layouts, and the Omacron also in the Silesian layout. But
the Latvian layouts and the Hawaiian do not contain any dead keys.
Only in the Maori and Silesian layouts these sequences with Amacron
and Omacron could be typed, but that was not why they were added.
More importantly, as James Cloos noted in issue #54, sequences like
`<dead_abovedot> <amacron>` for generating `ǡ` (that is: the macron
above the dot) are questionable, as in compose sequences generally
the first accent typed is the uppermost in the composed character.
Reference:
https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/54#note_17321
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Seventeen months ago, commits 78027fdb7a and 4f15cfc645 removed
these dashes from two of the man pages. Now, remove them all.
They are unhelpful and just make one wonder why they are there
(probably to function as improvised bullet points).
Also remove four leading spaces and a trailing comma.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
(Table 1 hard-wraps the first-column items in the same way.)
Also, correct the formatting of the subsequent paragraph.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Compose sequences for circled numbers, like ⑫ or ㉑, are nice to have,
but allowing them to be composed by typing one digit on the top row and
the other on the numerical keypad (or the other way around) is over the
top. Remove these absurd sequences. Keep only the sequences where both
digits are either on the top row or on the numerical keypad.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Prior to this, --enable-thread-safety-constructor would disable it,
while --disable worked as expected, and no option left it enabled as
expected by default. This also fixes the --help text to be displayed.
Fixes: afcdb6fb00
Reported-by: @igor.v.kovalenko
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
There is really no point in not being thread safe, I measured, all you
can see happen is noop performance gets like twice as slow and you have
thread safety bugs. And we're using xcb as the transport which means we
should expect threads in our clients anyway. Just do it.
This assumes your compiler understands __attribute__((constructor)). If
this is not your compiler, you can disable this with the appropriate
configure flag, but be aware you're asking for bugs.
Signed-off-by: Adam Jackson <ajax@redhat.com>
The Xserver made its own copy of this file in 2008, and the API's are
no longer the same between the server and client forks.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(Not that it will make any difference, as the checking of these
high bits looks like an excess of precaution.)
This fixes issue #134.
Reported-by: Rafał Mikrut
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
In the Ethiopian keyboard layout, the dead vowel keys do not produce <e>
and <u> and so on, but instead produce <U+FE69> and <U+FE75> and so on,
so the compose sequences should use those latter code points.
Also, include the basic compose sequences from en_US.UTF-8/Compose,
so that, when switching to a different layout in the Ethiopian locale,
all the usual compose sequences work too.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
These accents by themselves could only be produced when one had a
dead key for them, not with the help of the Multi key.
[Note that the sequences <dead_acute> <space> for apostrophe (')
and <dead_diaeresis> <space> for double quote (") are anomalies,
as normally <dead_accent> <space> produces the accent itself.]
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Compose sequences are meant to produce certain symbols by combining
certain different symbols, not to produce a symbol with the help of
the symbol itself.
This fixes issue #59.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The Khmer digraphs and Arabic ligatures have nothing to do with
Amharic or Greek.
(Also rewrap a comment and correct two others.)
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
XkbVirtualModsToReal should only fail to set mask if the server does
not support XKB, but it still made Oracle Parfait complain:
Error: Uninitialised memory
Uninitialised memory variable [uninitialised-mem-var] (CWE 457):
Possible access to uninitialised memory referenced by variable 'mask'
at line 863 of lib/libX11/src/xkb/XKBMisc.c in function 'XkbUpdateKeyTypeVirtualMods'.
Path in callee avoiding write at line 862
mask allocated at line 860
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
