Array `keysym_to_unicode_590_5fe` is only valid for range [0x590, 0x5fe] but current lower-bound is checked against 0x589.
So invalid values from 0x58a to 0x58f are being allowed by current check.
If any of these invalid value is passed as `keysym`, `keysym - 0x590` would underflow.
Signed-off-by: Gaurav Ujjwal <gujjwal00@gmail.com>
Commit 0bbc0d5e60 (from eight years ago) removed the lines that two
of these comments referred to. Without those lines, the comments don't
make sense any more. Reword and shorten them.
Also reword a comment about two sequences that don't work.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The letters ă and ŭ can already be composed with "u a" and "u u", but
ĕ, ğ, ĭ, and ŏ can be composed only with an uppercase U. Emancipate
the latter four and understand also a lowercase "u" to mean 'breve'.
(Yesterday I needed ğ and was annoyed that "u g" did not work.)
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
this was found by checking man pages with
groff -t -mandoc -Z -wmac -Tutf8 $FILE >/dev/null
In most cases .hN could be replaced with .BR
Signed-off-by: Walter Harms <wharms@bfs.de>
The missing macro is found via:
roff -t -mandoc -Z -wmac -Tutf8 XAnyEvent.man >/dev/null
To fix the problem the macro is replaced with .RB.
Signed-off-by: Walter Harms <wharms@bfs.de>
The normal form is 'C.UTF-8', but 'C.utf8' has been seen in the wild.
Fixes#102.
Reported-by: Tomas Korbar
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
While these are mostly called during teardown of larger structures
that are about to themselves be freed, there's no guarantee that
will always be the case, so try to be safer here.
[ This bug was found by the Parfait 4.0 bug checking tool.
http://labs.oracle.com/pls/apex/f?p=labs:49:::::P49_PROJECT_ID:13 ]
v2: Deduplicate & simplify pointer clearing in _XFreeEventCookies
as suggested by @keithp
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Resolves parfait warning of potential macro misinterpretation if
expanded in the midst of other arithmetic operations with higher
precedence.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Locale modifiers may be freed whenever XSetLocaleModifiers gets
called, even if the locale hasn't changed. This means that we cannot
save a pointer to those modifiers in the XimInstCallback record and
must, instead, make a copy of them instead.
This fixes a problem uncovered when running wish under libasan as
follows (on current Debian unstable):
$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6 wish
Reported-by: Vittorio Zecca <zeccav@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
v2:
Remove incorrect 'else' token found by @alanc
Using Arch as base distribution here because we can expect our dependencies to
be up-to-date. We rely on the Arch for our dependencies rather than building
those from git (notably: xorg-macros, xtrans and libxcb).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In poll_for_response is it possible that event replies are skipped
and a more up to date message reply is returned.
This will cause next poll_for_event call to fail aborting the program.
This was proved using some slow ssh tunnel or using some program
to slow down server replies (I used a combination of xtrace and strace).
How the race happens:
- program enters into poll_for_response;
- poll_for_event is called but the server didn't still send the reply;
- pending_requests is not NULL because we send a request (see call
to append_pending_request in _XSend);
- xcb_poll_for_reply64 is called from poll_for_response;
- xcb_poll_for_reply64 will read from server, at this point
server reply with an event (say sequence N) and the reply to our
last request (say sequence N+1);
- xcb_poll_for_reply64 returns the reply for the request we asked;
- last_request_read is set to N+1 sequence in poll_for_response;
- poll_for_response returns the response to the request;
- poll_for_event is called (for instance from another poll_for_response);
- event with sequence N is retrieved;
- the N sequence is widen, however, as the "new" number computed from
last_request_read is less than N the number is widened to N + 2^32
(assuming last_request_read is still contained in 32 bit);
- poll_for_event enters the nested if statement as req is NULL;
- we compare the widen N (which now does not fit into 32 bit) with
request (which fits into 32 bit) hitting the throw_thread_fail_assert.
To avoid the race condition and to avoid the sequence to go back
I check again for new events after getting the response and
return this last event if present saving the reply to return it
later.
To test the race and the fix it's helpful to add a delay (I used a
"usleep(5000)") before calling xcb_poll_for_reply64.
Original patch written by Frediano Ziglio, see
https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/34
Reworked primarily for readability by Peter Hutterer, see
https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/53
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This patch is based on research done by Dmitry Osipenko to uncover the
cause of a large class of Xlib lockups.
_XError must unlock and re-lock the display around the call to the
user error handler function. When re-locking the display, two
functions are called to ensure that the display is ready to generate a request:
_XIDHandler(dpy);
_XSeqSyncFunction(dpy);
The first ensures that there is at least one XID available to use
(possibly calling _xcb_generate_id to do so). The second makes sure a
reply is received at least every 65535 requests to keep sequence
numbers in sync (possibly generating a GetInputFocus request and
synchronously awaiting the reply).
If the second of these does generate a GetInputFocus request and wait
for the reply, then a pending error will cause recursion into _XError,
which deadlocks the display.
One seemingly easy fix is to have _XError avoid those calls by
invoking InternalLockDisplay instead of LockDisplay. That function
does everything that LockDisplay does *except* call those final two
functions which may end up receiving an error.
However, that doesn't protect the system from applications which call
some legal Xlib function from within their error handler. Any Xlib
function which cannot generate protocol or wait for events is valid,
including many which invoke LockDisplay.
What we need to do is make LockDisplay skip these two function calls
precisely when it is called from within the _XError context for the
same display.
This patch accomplishes this by creating a list of threads in the
display which are in _XError, and then having LockDisplay check the
current thread against those list elements.
Inspired-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Dmitry Osipenko <digetx@gmail.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Combining characters are not dead keys -- they have an immediate effect
and combine with the preceding character. So they cannot be used in
compose sequences.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Most locale context users call _XlcCurrentLC, which returns a pointer
which never needs to be passed to _XCloseLC, meaning it has unbounded
lifetime, so that locale data can never be freed.
Remove all reference counting and just leave all locales that were
ever used in memory.
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Martin Peres <martin.peres@mupuf.org>
These functions were caching encoding conversion functions in static
variables which is not thread safe. Let the conversion loader do its
job and cache locale to converters there. It's less efficient, but
it's also (now) thread safe.
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Martin Peres <martin.peres@mupuf.org>
It was strange that the accented letters Ž and ž can be composed with
sequences that start with "v" ("v Z" and "v z"), but not Č and č and
Š and š (and other letters with a caron). For these letters, compose
sequences that start with a "c" had to be used, which was frustrating
because it is hard to remember that "c" stands for "caron", AND the
graphically more obvious "v" is right next to it.
(Unfortunately, the sequence "v l" is already taken for vertical line.
Maybe the compose sequences for vertical line could be reduced to just
"V L" and "L V"?)
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
These artificial languages are meant to be international and are
thus not specific to any country. If one would want to support
aliases like ia_FR or ia_CH, then one would also have to support
ia_AU, ia_DE, ia_ES, et cetera, et cetera. That would be silly.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
They were found with:
while read one two; do
if [[ $one == $two: ]]; then echo $two; fi;
done <nls/locale.alias.pre
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
This function complements XSetIOErrorHandler(), allowing to override
the default behavior that trusts on I/O errors never coming back
(i.e. exit()ing the process).
This is meant as a mechanism for Wayland compositors (that are too
a X11 client + compositing manager) to unfasten seatbelts and jump
through the car window. It might get lucky and land on a stack of
pillows.
In consequence, some functions labeled as _X_NORETURN can as a
matter of fact return. So those hints were removed.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Ensure current state is cut short on _XIOError(), possible reentrancy
should be skipped through the XlibDisplayIOError flag checks.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
CPP is used to generate files, but as cpp reads files from the build host the
output has a number of blank lines at the beginning which varies depending on
what GCC and friends is used.
Pathalogical example:
$ cpp -undef -traditional /dev/null
# 1 "/dev/null"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 17 "/usr/include/stdc-predef.h" 3 4
[ 40 blank line ]
# 32 "<command-line>" 2
# 1 "/dev/null"
So depending on the content of stdc-predef.h and what other headers CPP will
load, the amount of whitespace in the generates files varies. This can result in
differences in reproducible environments, and file conflicts in multilib
environments.
As whitespace is irrelevant to these machine-readable files, extend the sed to
just delete blank lines.
If the compiler knows of a better algorithm for counting the number of
bits set in a word for the target CPU, let it use that, instead of the
classic algorithm optimized for PDP-6.
Based on libXext commit 490a25e6f8a4d2482af4364c700b68ad11a4d10b
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reported by valgrind:
```
==118175== 17 bytes in 1 blocks are definitely lost in loss record 13 of 1,675
==118175== at 0x483A809: malloc (vg_replace_malloc.c:307)
==118175== by 0x5CD1B46: _XlcDefaultMapModifiers (in /usr/lib64/libX11.so.6.3.0)
==118175== by 0x5CD1F1A: XSetLocaleModifiers (in /usr/lib64/libX11.so.6.3.0)
==118175== by 0x496841C: X11_InitKeyboard (SDL_x11keyboard.c:324)
==118175== by 0x496F0CA: X11_VideoInit (SDL_x11video.c:455)
==118175== by 0x494747B: SDL_VideoInit_REAL (SDL_video.c:532)
==118175== by 0x489E886: SDL_InitSubSystem_REAL (SDL.c:206)
==118175== by 0x402634: main (fade.cc:35)
```
While we don't expect large enough ints to need it, we don't
enforce a maximum size, so gcc assumes the worst and warns:
../../../src/xlibi18n/lcUTF8.c: In function ‘create_tofontcs_conv’:
../../../src/xlibi18n/lcUTF8.c:1736:34: warning: ‘.charset.name’ directive output may be truncated writing 13 bytes into a region of size between 8 and 17 [-Wformat-truncation=]
1736 | snprintf(buf, sizeof(buf), "fs%d.charset.name", i);
| ^~~~~~~~~~~~~
../../../src/xlibi18n/lcUTF8.c:1736:2: note: ‘snprintf’ output between 17 and 26 bytes into a destination of size 20
1736 | snprintf(buf, sizeof(buf), "fs%d.charset.name", i);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../src/xlibi18n/lcUTF8.c:1739:46: warning: ‘snprintf’ output may be truncated before the last format character [-Wformat-truncation=]
1739 | snprintf(buf, sizeof(buf), "fs%d.charset", i);
| ^
../../../src/xlibi18n/lcUTF8.c:1739:6: note: ‘snprintf’ output between 12 and 21 bytes into a destination of size 20
1739 | snprintf(buf, sizeof(buf), "fs%d.charset", i);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../src/xlibi18n/lcUTF8.c:1754:41: warning: ‘.charset.name’ directive output may be truncated writing 13 bytes into a region of size between 8 and 17 [-Wformat-truncation=]
1754 | snprintf(buf, sizeof(buf), "fs%d.charset.name", i);
| ^~~~~~~~~~~~~
../../../src/xlibi18n/lcUTF8.c:1754:9: note: ‘snprintf’ output between 17 and 26 bytes into a destination of size 20
1754 | snprintf(buf, sizeof(buf), "fs%d.charset.name", i);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../src/xlibi18n/lcUTF8.c:1757:53: warning: ‘snprintf’ output may be truncated before the last format character [-Wformat-truncation=]
1757 | snprintf(buf, sizeof(buf), "fs%d.charset", i);
| ^
../../../src/xlibi18n/lcUTF8.c:1757:13: note: ‘snprintf’ output between 12 and 21 bytes into a destination of size 20
1757 | snprintf(buf, sizeof(buf), "fs%d.charset", i);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Avoids gcc warnings that we're using strncpy wrong to copy a known-length
set of characters without a terminating '\0' to a buffer whose length we
are checking separately. (Should also be imperceptibly faster since we
no longer check if each byte is '\0' when we already know it won't be.)
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Quiets gcc 10.2 warning of:
src/xcms/LRGB.c: In function ‘LINEAR_RGB_InitSCCData’:
src/xcms/LRGB.c:798:1: warning: label ‘FreeBlueTblElements’ defined
but not used
[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wunused-label-Wunused-label]
798 | FreeBlueTblElements:
| ^~~~~~~~~~~~~~~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
