Don't try to divide through a signed char when indexing an array, lest
ye try to index off the start of it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The only time we could ever hit this was with count == 0, which seems
unnecessarily pedantic. But OK.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Every user of ExprReturnLhs goes on to unconditionally dereference the
field return, which can be NULL if xkb_intern_atom fails. Return false
if this is the case, so we fail safely.
testcase: splice geometry data into interp
Signed-off-by: Daniel Stone <daniels@collabora.com>
If we have an expression of the form 'l1' in an interp section, we
unconditionally try to dereference its args, even if it has none.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If the scanner indicates that we might have something which looks like a
map, but the parser in fact fails to create that map, we will try to
access the map regardless. Stop doing that.
testcase: 'xkb_keymap {' -> '#kb_keymap'
Signed-off-by: Daniel Stone <daniels@collabora.com>
Coverity complains that a 7-byte string may not be null-terminated when copied
into act->data (size 7). This is fine, make a note of it.
All the strings in xkeyboard-config only use 6 bytes + null terminator so this
won't be an issue. The server (the only user of these) uses an 8-byte array
and forcibly null-terminates the string, see XkbDDXPrivate().
Everything else treats it as byte-array size 7 anyway so whether it's
null-terminated doesn't matter.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Move the aliases copy to within the (num_key_aliases > 0) block.
Passing info->aliases into this fuction with invalid aliases will
cause log messages but num_key_aliases stays on 0. The key_aliases array
is never allocated and remains NULL. We then loop through the aliases, causing
a null-pointer dereference.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's a (theoretical?) path where we might end up strcpy() buf without ever
writing to it. This happens if the mask is nonzero but specifies a modifier
larger than the one in the xkb_mod_set.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The parser would enter an infinite loop if an unterminated keysym
literal occurs at EOF.
Found with the afl fuzzer.
Signed-off-by: Ran Benita <ran234@gmail.com>
xkb_geometry sections are ignored; previously the had done so by
returning NULL for the section's XkbFile, however some sections of the
code do not expect this. Instead, create an XkbFile for it, it will
never be processes and discarded later.
Caught with the afl fuzzer.
Signed-off-by: Ran Benita <ran234@gmail.com>
In the XKB format, floats and various keywords can only be used in the
xkb_geometry section. xkbcommon removed support xkb_geometry, but still
parses it for backward compatibility. As part of ignoring it, the float
AST node and various keywords were removed, and instead NULL was
returned by their parsing actions. However, the rest of the code does
not handle NULLs, and so when they appear crashes usually ensue.
To fix this, restore the float AST node and the ignored keywords. None
of the evaluating code expects them, so nice error are displayed.
Caught with the afl fuzzer.
Signed-off-by: Ran Benita <ran234@gmail.com>
The expression evaluator would go into an infinite recursion when
evaluating something like this as a boolean: `!True`. Instead of
recursing to just `True` and negating, it recursed to `!True` itself
again.
Bug inherited from xkbcomp.
Caught with the afl fuzzer.
Signed-off-by: Ran Benita <ran234@gmail.com>
Though text formats aren't exactly fuzzer's strong suit, fuzzers can
catch many surface-level bugs.
The fuzz/ directory contains target programs, testcases and dictionaries
to drive the afl fuzzer.
This commit adds a fuzzer for the XKB keymap text format and the Compose
text format. On my slow machine, using a single core, a full cycle of
the XKB fuzzer takes 5 hours. For Compose, it takes a few minutes.
Fuzzing for the other file formats (rules files mostly) will be added
later.
To do some fuzzing, run `./fuzz/fuzz.sh`.
Signed-off-by: Ran Benita <ran234@gmail.com>
Old meson expects an array with one dependency per element. Providing a
string containing multiple deps results in only the first dep getting
its whitespace properly applied. As a result, the output was:
Requires.private: xcb >= 1.10 xcb-xkb>=1.10
And downstream projects failed to find a package named 'xcb-xkb>=1.10'.
Specifying an array of versioned deps results in correct output:
Requires.private: xcb >= 1.10, xcb-xkb >= 1.10
Fixes#64.
Signed-off-by: Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>
The meson-generated pkgconfig file was missing Requires and
Requires.private.
[ran: adjust for older Meson versions.]
Signed-off-by: Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
Trim the API a bit.
Also, just always use gettimeofday(), which is portable. Hopefully the
system clock doesn't change while a benchmark is running.
Signed-off-by: Ran Benita <ran234@gmail.com>
The CI image only has Python 3.4. It's a bit of a hassle to change this,
so let's pin meson to the version before they bumped their requirement
instead.
I suppose it's not that bad in that it will guarantee compatibility with
older meson over time.
Signed-off-by: Ran Benita <ran234@gmail.com>
Will be deprecated in automake 2.0.
Replaced by AC_CONFIG_MACRO_DIR (already present) which is available
since autoconf 2.63.
Signed-off-by: Ran Benita <ran234@gmail.com>
The x11 tests/demos did not depend on xcb and xcb-xkb directly, only
indirectly through link_with: libxkbcommon_x11_internal. So linking
worked, but the xcb and xcb-xkb cflags were *not* included when
compiling them. So when using xcb installed in a non-standard location,
what would happen is:
- Library will link with custom xcb and compile with custom xcb headers.
- Test will link with custom xcb and compile with system xcb headers (if
exist, otherwise fail).
Fixes: https://github.com/xkbcommon/libxkbcommon/issues/57
Reported-by: @remexre
Signed-off-by: Ran Benita <ran234@gmail.com>
We will never remove the deprecated functions and there is no real
reason to annoy users into stop using them.
If there *will* be a reason, *then* we will add the attribute.
Fixes: https://github.com/xkbcommon/libxkbcommon/issues/56
Signed-off-by: Ran Benita <ran234@gmail.com>
The default fallback type uses
type->level_names = NULL
but the keymap-dump code was not checking this case.
Instead of adding more workarounds and possible bugs (e.g. previous
commit), let's just keep the number of level names separately. This has
the additional advantage retains extraneous level name if someone adds
them for some reason.
Signed-off-by: Ran Benita <ran234@gmail.com>
The buggy code assigned the number of levels based on the number of
level names in the definition, instead of the actual number of levels!
This would completely break type definitions which do not give names to
levels.
This was not noticed for so long because xkeyboard-config always gives
names to all levels.
This regressed in 61fed8dab9.
Reported-by: Gatis Paeglis <gatis.paeglis@qt.io>
Signed-off-by: Ran Benita <ran234@gmail.com>
These can be useful in some odd cases.
There is already an implementation (+ tests) for internal use, so all
that's needed is to export them.
If xkbcommon were to provide a way to convert a Unicode codepoint to a
keysym, this could have been implemented externally as follows:
uint32_t codepoint = xkb_keysym_to_utf32(keysym);
uint32_t upper_codepoint = my_unicode_library_to_upper(codepoint);
xkb_keysym_t upper_keysym = theoretical_xkb_keysym_from_utf32(upper_codepoint);
However keysym -> codepoint is not injective so such a function is not
possible strictly speaking.
Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone
Ran Benita
Peter Hutterer
Jan Alexander Steffens (heftig)
Matt Whitlock