There are two issues with the use of `UCSConvertCase` in `XConvertCase`:
- Some Latin-1 keysyms do not map within Latin-1, e.g. `ssharp`.
Only Latin-1 keysyms have the same value as the Unicode code point of
their corresponding character. So `UCSConvertCase` does not work for
some Latin-1 keysyms as it returns Unicode code points outside Latin-1
that do not match their corresponding keysyms values.
- Some Unicode keysyms should map to Latin-1 keysyms (<0x100). But the
Unicode keysym mask 0x01000000 is applied blindly to the result of
`UCSConvertCase`, resulting in invalid Unicode keysyms (0x010000nn)
while they should be Latin-1 keysyms.
Example with ß/ẞ:
```c
KeySym lower, upper;
XConvertCase(XK_ssharp, &lower, &upper);
// Expected: lower == XK_ssharp, upper == U1E9E
// Got: lower == XK_ssharp, upper == 0x1E9E
XConvertCase(U1E9E, &lower, &upper);
// Expected: lower == XK_ssharp, upper == U1E9E
// Got: lower == 0x10000df, upper == U1E9E
```
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/274>
Clears 8 warnings from clang of the form:
imDefIc.c:366:29: warning: empty expression statement has no effect;
remove unnecessary ';' to silence this warning [-Wextra-semi-stmt]
XIM_SET_PAD(&buf_s[2], len); /* pad */
^
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/272>
Clears 10 warnings from clang of the form:
xcb_io.c:177:56: warning: empty expression statement has no effect;
remove unnecessary ';' to silence this warning [-Wextra-semi-stmt]
xcb_xlib_unknown_req_in_deq);
^
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/272>
Clears 24 warnings from clang of the form:
TextExt16.c:63:34: warning: empty expression statement has no effect;
remove unnecessary ';' to silence this warning [-Wextra-semi-stmt]
CI_GET_DEFAULT_INFO_1D (fs, def);
^
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/272>
Clears 5 warnings from clang of the form:
RdBitF.c:141:32: warning: empty expression statement has no effect;
remove unnecessary ';' to silence this warning [-Wextra-semi-stmt]
RETURN (BitmapFileInvalid);
^
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/272>
Clears 3 warnings from clang of the form:
PolyReg.c:224:67: warning: empty expression statement has no effect;
remove unnecessary ';' to silence this warning [-Wextra-semi-stmt]
BRESINITPGONSTRUCT(dy, top->x, bottom->x, pETEs->bres);
^
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/272>
Clears 4 warnings from clang of the form:
ParseCmd.c:158:43: warning: empty expression statement has no effect;
remove unnecessary ';' to silence this warning [-Wextra-semi-stmt]
PutCommandResource(options[i].value);
^
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/272>
Clears 4 warnings from clang of the form:
CrGlCur.c:140:64: warning: empty expression statement has no effect;
remove unnecessary ';' to silence this warning [-Wextra-semi-stmt]
GetFunc (TryShapeCursorFunc, "XcursorTryShapeCursor", func);
^
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/272>
Makes them match the style of the other macros here and clears
up 5 clang warnings of the form:
Context.c:194:27: warning: empty expression statement has no effect;
remove unnecessary ';' to silence this warning [-Wextra-semi-stmt]
_XCreateMutex(&db->linfo);
^
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/272>
Clears 13 warnings from clang of the form:
Backgnd.c:44:72: warning: empty expression statement has no effect;
remove unnecessary ';' to silence this warning [-Wextra-semi-stmt]
OneDataCard32 (dpy, NEXTPTR(req,xChangeWindowAttributesReq), pixel);
^
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/272>
Clears 6 warnings from clang of the form:
XKBBind.c:74:48: warning: empty expression statement has no effect;
remove unnecessary ';' to silence this warning [-Wextra-semi-stmt]
_XkbCheckPendingRefresh(dpy, dpy->xkb_info);
^
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/272>
Clears 4 warnings from clang of the form:
lcUtil.c:53:18: warning: empty expression statement has no effect;
remove unnecessary ';' to silence this warning [-Wextra-semi-stmt]
set_toupper(ch1);
^
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/272>
Clears 38 warnings from clang of the form:
cmsLkCol.c:155:35: warning: empty expression statement has no effect;
remove unnecessary ';' to silence this warning [-Wextra-semi-stmt]
Data (dpy, colorname, (long)n);
^
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/272>
Clears 12 warnings from clang of the form:
cmsCmap.c:194:34: warning: empty expression statement has no effect;
remove unnecessary ';' to silence this warning [-Wextra-semi-stmt]
DeqAsyncHandler(dpy, &async);
^
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/272>
Found by Oracle Parfait 13.3 static analyzer:
X Resource Leak [X-resource-leak]:
Leaked X Resource window
at line 306 of imDefIm.c in function '_XimPreConnectionIM'.
window initialized at line 300 with XCreateSimpleWindow
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/269>
Avoids build failures with gcc 14.2 when MALLOC_0_RETURNS_NULL is defined:
imCallbk.c:346:9: error: ‘memcpy’ offset 10 is out of the bounds [0, 1]
[-Werror=array-bounds=]
346 | memcpy(&buf[p],&cbrec.text->string.mbs,length_in_bytes);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/267>
Avoids build failures with gcc 14.2 when MALLOC_0_RETURNS_NULL is defined:
imDefIm.c: In function ‘_XimEncodingNegotiation’:
imDefIm.c:1739:15: error: ‘memcpy’ offset 8 is out of the bounds [0, 1]
[-Werror=array-bounds=]
1739 | (void)memcpy((char *)&buf_s[2], name_ptr, name_len);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/267>
Clears warning from gcc 14.1:
SetFPath.c: In function ‘XSetFontPath’:
../include/X11/Xlibint.h:463:24: warning: argument 1 value is zero
[-Walloc-zero]
463 | # define Xmalloc(size) malloc((size_t)(size))
| ^~~~~~~~~~~~~~~~~~~~~~
SetFPath.c:61:18: note: in expansion of macro ‘Xmalloc’
61 | if ((p = Xmalloc (nbytes))) {
| ^~~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/266>
Commit 1472048b7 to fix a colormap threading issue added a display
lock/unlock and a call to SyncHandle() to _XcmsFreeClientCmaps().
When running synchronized, that means calling XSync().
_XcmsFreeClientCmaps() is called from _XFreeDisplayStructure() via
XCloseDisplay() after the xcb connection is closed.
So when running synchronized, we may end up calling XSync() after the
xcb connection to the display is closed, which will generate a spurious
XIO error:
| #0 in _XDefaultIOError () at /lib64/libX11.so.6
| #1 in _XIOError () at /lib64/libX11.so.6
| #2 in _XReply () at /lib64/libX11.so.6
| #3 in XSync () at /lib64/libX11.so.6
| #4 in _XSyncFunction () at /lib64/libX11.so.6
| 8#5 in _XFreeDisplayStructure () at /lib64/libX11.so.6
| 8#6 in XCloseDisplay () at /lib64/libX11.so.6
To avoid that issue, closed the xcb connection to the display last.
v2: And same in OutOfMemory() as well (José Expósito)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/264>
Xlib is now built with threading support enabled from the constructor
by default.
XRebindKeysym() acquires the display lock, then calls:
| XRebindKeysym()
| LockDisplay()
| ComputeMaskFromKeytrans()
| -> XkbKeysymToModifiers()
| -> _XkbLoadDpy()
| -> XkbGetMap()
| -> XkbGetUpdatedMap()
| LockDisplay()
And the dead lock:
| Xlib ERROR: XKBGetMap.c line 575 thread 1fc6e580: locking display already
| locked at KeyBind.c line 937
To avoid the issue, call ComputeMaskFromKeytrans() from outside the display
lock.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/216
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/256>
That commit 99a2cf1aa was moving the calls to the _Xcms*CmapRec*()
family of functions within a display lock to make the XCMS colormap
functions thread safe.
Unfortunately, that causes a deadlock in XCopyColormapAndFree(), because
_XcmsCopyCmapRecAndFree() calls CmapRecForColormap() which calls
XGetVisualInfo() which also tries to acquire the display lock.
So, instead of moving the entire functions within the display lock,
let's try to make the functions themselves thread safe in the following
commit, and revert this change which causes a deadlock.
This reverts commit 99a2cf1aa0.
Fixes: https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/215
See-also: https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/94
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/254>
Ezh is a Latin-Script letter belonging to several Uralic, Caucasian,
and West-African languages. It is present on some Finnish keyboards,
but users of many other layouts cannot presently type it. This commit
adds Multi_key sequences for both Capital and lowercase Ezh, as well
as Multi_key + dead_caron sequences for Ezh with a caron, which is
used in Laz and Skolt Sámi.
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/221>
JCUKEN (ЙЦУКЕН) - the default and de-facto standard layout for most Cyrillic scripts - lacks a number of ASCII symbols from QWERTY counterpart, forcing users to switch back-and-forth between layouts to type them.
This adds sequences for them to the ru_RU compose map in an intuitive and consistent manner.
Fixes#200 for ru_RU (but other Cyrillic layouts might benefit too)
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/238>
These sequences are intended for use in the ara(mac-phonetic) and
my(phonetic) layouts. They are based on the following layouts listed in
the CLDR:
- https://github.com/unicode-org/cldr/blob/release-43/keyboards/osx/ar-t-k0-osx-qwerty.xml
- https://github.com/unicode-org/cldr/blob/release-43/keyboards/osx/ms-t-k0-osx.xml
The sequences are listed in the `<transforms>` section, and are
reproduced below:
```
<transforms type="simple">
<transform from="ء\u{64E}" to="آ"/> <!-- ءَ → آ -->
<transform from="ء\u{650}" to="إ"/> <!-- ءِ → إ -->
<transform from="ء " to="ء"/>
<transform from="ء\u{A0}" to="ء"/>
<transform from="ء!" to="إ"/>
<transform from="ء١" to="إ"/>
<transform from="ءا" to="أ"/>
<transform from="ءس" to="ئ"/>
<transform from="ءو" to="ؤ"/>
<transform from="ءي" to="ئ"/>
<transform from="ءى" to="ئ"/>
</transforms>
```
We limit ourselves to the sequences that strictly combine a character
and a hamza, and generate that character with a hamza on it, following
the behavior in sequences of other dead keys. Additional sequences,
potentially for other layouts as well, could be added later on as
necessary.
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/218>
When `num_fields == 12`, if the last character of the pattern is '-',
the `buf` array is overrun.
This error has been found by a static analysis tool. This is the report:
Error: OVERRUN (CWE-119):
libX11-1.8.7/modules/om/generic/omGeneric.c:691: cond_at_most:
Checking "length > 255" implies that "length" may be up to 255 on
the false branch.
libX11-1.8.7/modules/om/generic/omGeneric.c:695: alias:
Assigning: "last" = "buf + length - 1". "last" may now point to as
high as byte 254 of "buf" (which consists of 256 bytes).
libX11-1.8.7/modules/om/generic/omGeneric.c:718: ptr_incr:
Incrementing "last". "last" may now point to as high as byte 255
of "buf" (which consists of 256 bytes).
libX11-1.8.7/modules/om/generic/omGeneric.c:720: ptr_incr:
Incrementing "last". "last" may now point to as high as byte 256
of "buf" (which consists of 256 bytes).
libX11-1.8.7/modules/om/generic/omGeneric.c:720: overrun-local:
Overrunning array of 256 bytes at byte offset 256 by
dereferencing pointer "++last".
# 718| *++last = '*';
# 719|
# 720|-> *++last = '-';
# 721| break;
# 722| case 13:
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>
This error has been found by a static analysis tool. This is the report:
Error: RESOURCE_LEAK (CWE-772):
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1316: alloc_fn:
Storage is returned from allocation function "calloc".
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1316: var_assign:
Assigning: "tmp" = storage returned from
"calloc((size_t)((buf_size + data_len == 0) ? 1 : (buf_size + data_len)), 1UL)".
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1319: noescape:
Resource "tmp" is not freed or pointed-to in "memcpy".
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1320: var_assign:
Assigning: "buf" = "tmp".
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1302: var_assign:
Assigning: "data" = "buf".
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1303: noescape:
Resource "data" is not freed or pointed-to in
"_XimEncodeIMATTRIBUTE".
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1333: leaked_storage:
Variable "data" going out of scope leaks the storage it points to.
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1333: leaked_storage:
Variable "buf" going out of scope leaks the storage it points to.
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1333: leaked_storage:
Variable "tmp" going out of scope leaks the storage it points to.
# 1331|
# 1332| if (!total)
# 1333|-> return (char *)NULL;
# 1334|
# 1335| buf_s = (CARD16 *)&buf[XIM_HEADER_SIZE];
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>
Passing a negative value in `needed` to the `XkbResizeKeyActions()`
function can create a `newActs` array of an unespected size.
Check the value and return if it is invalid.
This error has been found by a static analysis tool. This is the report:
Error: OVERRUN (CWE-119):
libX11-1.8.7/src/xkb/XKBMAlloc.c:811: cond_const:
Checking "xkb->server->size_acts == 0" implies that
"xkb->server->size_acts" is 0 on the true branch.
libX11-1.8.7/src/xkb/XKBMAlloc.c:811: buffer_alloc:
"calloc" allocates 8 bytes dictated by parameters
"(size_t)((xkb->server->size_acts == 0) ? 1 : xkb->server->size_acts)"
and "8UL".
libX11-1.8.7/src/xkb/XKBMAlloc.c:811: var_assign:
Assigning: "newActs" = "calloc((size_t)((xkb->server->size_acts == 0) ? 1 : xkb->server->size_acts), 8UL)".
libX11-1.8.7/src/xkb/XKBMAlloc.c:815: assignment:
Assigning: "nActs" = "1".
libX11-1.8.7/src/xkb/XKBMAlloc.c:829: cond_at_least:
Checking "nCopy > 0" implies that "nCopy" is at least 1 on the
true branch.
libX11-1.8.7/src/xkb/XKBMAlloc.c:830: overrun-buffer-arg:
Overrunning buffer pointed to by "&newActs[nActs]" of 8 bytes by
passing it to a function which accesses it at byte offset 15
using argument "nCopy * 8UL" (which evaluates to 8).
# 828|
# 829| if (nCopy > 0)
# 830|-> memcpy(&newActs[nActs], XkbKeyActionsPtr(xkb, i),
# 831| nCopy * sizeof(XkbAction));
# 832| if (nCopy < nKeyActs)
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>
In the `res->resource_size == XimType_NEST` code path, if
`res->xrm_name != pre_quark` and `res->xrm_name != sts_quark`, `len` can
be used uninitialized.
This error has been found by a static analysis tool. This is the report:
Error: UNINIT (CWE-457):
libX11-1.8.7/modules/im/ximcp/imRmAttr.c:1106: var_decl:
Declaring variable "len" without initializer.
libX11-1.8.7/modules/im/ximcp/imRmAttr.c:1179: uninit_use:
Using uninitialized value "len".
# 1177| }
# 1178|
# 1179|-> if (len == 0) {
# 1180| continue;
# 1181| } else if (len < 0) {
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>
