For the Cyrillic YU with combining acute accent, the string between
the quotes contained two U+0301 code points, whereas one is enough,
like for all the neighboring strings.
(This duplication was found by accident with `nano --mini --cons`.)
Fixes CVE-2023-3138: X servers could return values from XQueryExtension
that would cause Xlib to write entries out-of-bounds of the arrays to
store them, though this would only overwrite other parts of the Display
struct, not outside the bounds allocated for that structure.
Reported-by: Gregory James DUCK <gjduck@gmail.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
First: combining diacritics like the combining long solidus (`U+0338`)
are not meant to be used in compose sequences. Second: there is just
one layout in xkeyboard-config that contains the `U0338` character:
the deprecated/obsolete German T3 layout. So, practically speaking,
these compose sequences with `U0338` were untypable. So, use a slash
instead, that almost all layouts have. This does require that the
sequence `<Compose> <less> <slash>` changes its meaning from backslash
to not-less-than (`≮`). This seems like an acceptable sacrifice, as
the sequence `<Compose> <slash> <slash>` is a faster/easier sequence
for the backslash and most layouts contain a backslash already anyway.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
None of the layouts in xkeyboard-config contain `Ohook` or `Uhook`
or `U+01D3` (U with caron) nor their lowercase forms, so these six
sequences cannot be typed on any known keyboard.
(Also, the target characters of the sequences with hook and horn
seem to occur only in Vietnamese, where the horn is part of the
vowel and the hook is a tonal mark. All Vietnamese layouts in
xkeyboard-config contain `Ohorn` and `Uhorn`, and then the five
tonal marks as dead keys, `dead_hook` among them. It does not
make sense to want to apply a horn to a vowel that already has
a tonal mark, nor is it possible with the Vietnamese layouts.)
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Last year, commit 488b156fe2 changed mistaken ASCII characters to the
code points that were actually used in the Ethiopian keyboard layout.
But those code points were mistaken too: the intention was not to use
the code point U+FE68 in the layout but the raw symbol code 0xfe68 --
and so on for the other codes. The symbols that these raw codes were
intended to refer to were `dead_a` and friends. But these dead vowels
were added under different codes: 0xfe80 to 0xfe8b.
So, correct the Amharic compose sequences to make use of the dead-vowel
symbols that were specifically added for them fifteen years ago.
(As soon as this is merged, xkeyboard-config wil be changed too to use
the dead vowels in the Ethiopian layout.)
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
This sequence has already been defined in the iso8859-9e compose
file meant for the Azerbaijani locale, yet for the longest time, only
the lowercase form has existed in the en_US.UTF-8 master compose
file. This patch adds one sequence for Latin Capital Letter Schwa for
the Azerbaijani language.
Additionally, the sequence in the pt_BR.UTF-8 locale for capital
schwa has been removed as it uses two lowercase e's as part of its
sequence, which in practice would make typing both `Multi_key e e`
and `Multi_key E E` output capital schwa.
Four years ago, while removing private macros, commit fe46eb2871
unintentionally truncated the XSetScreenSaver manpage. Restore
the snipped part (minus trailing spaces and a mistaken singular).
This fixes issue #187.
Reported-by: Sergio Gelato
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
These sequences appear to be a leftover artifact of auto-generating
dead_currency sequences for cent and the cedi sign, where chaining
with ascii "c" vs "ccedilla" would output cent vs the cedi sign
respectively, but somehow this ended up creating strange sequences
with dead_cedilla followed by cent or the colon sign to output the
cedi sign, the latter sequence of which was already removed recently.
Additionally, sequences beginninng with dead_cedilla followed by
currency have been removed as they also appear to be related to these
artifacts. The two remaining sequences beginning with dead_currency
followed by dead_cedilla are maintained and moved to the stretch of
dead_currency sequences next to ccedilla, and sorted in order of
unicode decompositional complexity.
None of the keyboard layouts in xkeyboard-config contains accented
Greek characters like `Greek_alphaaccent` or `Greek_iotadieresis`
(nor in their Unicode hexadecimal forms, like U03AC or 0x10003CA),
so none of these sequences could be typed on an existing layout.
Also, the two sequences that started with `Greek_accentdieresis`
were plain wrong: making a spacing character into a dead key.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
None of the keyboard layouts in xkeyboard-config contains code points
in the range U+1F00..U+1FFF (the Greek Extended block), so none of the
removed sequences could be typed on an existing layout.
(Of course it is possible that some people have their own private layout
that contains some of the Greek Extended characters, but if they do,
then they can also define private compose sequences, when needed.)
Modern Greek does not use these characters with polytonic diacritics
anyway -- they are useful only for typing traditional Greek.
The useless sequences were removed with this command:
sed -i '/<U1F..>/d' nls/en_US.UTF-8/Compose.pre
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
AC_PROG_LIBTOOL was replaced by LT_INIT in libtool 2 in 2008,
so it's time to rely on it.
Clears autoconf warnings:
configure.ac:20: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
configure.ac:20: You should run autoupdate.
m4/libtool.m4💯 AC_PROG_LIBTOOL is expanded from...
configure.ac:20: the top level
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Needed for builds on NetBSD to work correctly, since it depends on
AC_USE_SYSTEM_EXTENSIONS defining _OPENBSD_SOURCE to expose the
prototype for reallocarray() in the system headers.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Two compose sequences (with plain ASCII characters) existed for
the lowercase b with stroke (ƀ) but not for the capital one (Ƀ).
This addresses part of issue #166.
Reported-by: J. McWilliams
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
There is not any keyboard layout (in xkeyboard-config) that contains
`obelowdot` or `ubelowdot`, so having compose sequences that use these
symbols is pointless.
There are some layouts that contain `otilde` (and one that contains
`utilde`), but those layouts then do not contain `dead_horn`, so
the compose sequences that combine the two symbols are pointless.
There are a few layouts that contain U+0256, U+025C, U+025F or U+0279,
but those layouts do not contain `dead_hook`, so the compose sequences
that combine the latter with one of the former are pointless.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The various compose sequences with the accents in their proper order
(the highest placed accent first) continue to exist.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
This reverts commit d6d6cba902.
The reverted commit intended to fix the problem where an unpadded X
event struct is passed into XPutBackEvent, by creating a padded struct
with _XEventToWire and _XWireToEvent. However, _XWireToEvent updates the
last sequence number in Display, which may cause xlib to complain about
lost sequence numbers.
IMO, the problem that commit tried to solve is a bug in the client
library, and workaround it inside Xlib is bad practice, especially given
the problem it caused. Plus, the offender cited in the original commit
message, freeglut, has already fixed this problem.
Fixes: #176#174
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
It seems to be common practice of some X11 clients to pass specific event
types into APIs that take XEvent*. For example, freeglut does:
XConfigureEvent fakeEvent = {0};
...
XPutBackEvent(fgDisplay.Display, (XEvent*)&fakeEvent);
This can result in reads overflowing the input event when libX11 does:
XEvent store = *event;
=================================================================
==75304==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x00016ee4a8e8 at pc 0x000101c54d14 bp 0x00016ee4a0d0 sp 0x00016ee49888
READ of size 192 at 0x00016ee4a8e8 thread T0
#0 0x101c54d10 in __asan_memcpy+0x1a4 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3cd10)
#1 0x102848a18 in _XPutBackEvent PutBEvent.c:41
#2 0x1028490a4 in XPutBackEvent PutBEvent.c:84
#3 0x1013295c8 in fgOpenWindow freeglut_window.c:1178
#4 0x101321984 in fgCreateWindow freeglut_structure.c:108
#5 0x10132b138 in glutCreateWindow freeglut_window.c:1551
#6 0x100fb7d94 in main+0x78 (checkeredTriangles:arm64+0x100003d94)
#7 0x197de3e4c (<unknown module>)
Address 0x00016ee4a8e8 is located in stack of thread T0 at offset 840 in frame
#0 0x1013282f8 in fgOpenWindow freeglut_window.c:1063
This frame has 8 object(s):
[32, 40) 'title.addr'
[64, 176) 'winAttr' (line 1066)
[208, 240) 'textProperty' (line 1067)
[272, 352) 'sizeHints' (line 1068)
[384, 440) 'wmHints' (line 1069)
[480, 672) 'eventReturnBuffer' (line 1070)
[736, 740) 'num_FBConfigs' (line 1072)
[752, 840) 'fakeEvent' (line 1074) <== Memory access at offset 840 overflows this variable
This change allows XPutBackEvent() to support such clients without
risk of memory read overflow.
Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Tested-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Use the same indentation as the surrounding code.
Signed-off-by: Ulrich Sibiller <uli42@gmx.de>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
- the activation logic is reversed
- there is also _XInternalLockDisplay() that needs protection
- I've found cases (in fvwm2) where the callback calls XCheckIfEvent()
recursively. So the flag needs to be a counter.
Reviewed-by: Adam Jackson <ajax@redhat.com>
