The current test is incorrect, since 'map[None]' is entirely valid. In
most cases this doesn't cause any problems, since the default fallback
is Level1, and it's almost always 'map[None] = Level1' anyway. But in
one case in xkeyboard-config it isn't, in types/numpad(mac):
type "KEYPAD" {
modifiers = None;
map[None] = Level2;
level_name[Level2] = "Number";
};
So before checking if no modifiers were mapped, make sure there *were*
any modifiers at all.
https://bugs.freedesktop.org/show_bug.cgi?id=85092
Reported-by: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
The keysym cache for the new scanner was not initialized.
To avoid such errors also in the future, require passing the priv
argument in scanner_init(), instead of initializing it separately.
Signed-off-by: Ran Benita <ran234@gmail.com>
If we have a big array which can be finalized, on average we can give
back 1/4 of its size, which the allocator might be able to use.
Signed-off-by: Ran Benita <ran234@gmail.com>
Replace the dog-slow unneeded strncasecmp() with an inlineable memcmp().
Before:
compiled 2500 keymaps in 8.348715629s
After:
compiled 2500 keymaps in 7.872640338s
Signed-off-by: Ran Benita <ran234@gmail.com>
The "width" terminology comes from the group*width+level layout of the
keysyms in a key, as used in the old implementations. We don't keep all
the keysyms of a key in one array so change it to a more accurate name.
Signed-off-by: Ran Benita <ran234@gmail.com>
An mlvo can also be used in an expansion, but we didn't mark them in
this case in commit d8a4f52cb9. This caused wrongful warnings on
something like -l ch -v fr -- the `fr` is only added via expansion.
Signed-off-by: Ran Benita <ran234@gmail.com>
Due to wildcard matches in the rules file, this is only really useful
for misspelled or missing options, e.g.
$ ./test/rmlvo-to-kccgst -o comprose:ralt > /dev/null
xkbcommon: ERROR: Unrecognized RMLVO option "comprose:ralt" was ignored
Although it is more of a warning, it indicates a misconfiguration which
the user probably wants to see. Therefore the log level is ERROR.
Signed-off-by: Ran Benita <ran234@gmail.com>
Remove the deprecated symbols that were used for ABI compatibility
during the transition period to the first stable version, 0.2.0.
The old *names* can still be used, programs which use the old names will
continue to work, as long as they were compiled against a stable
version (as they have been #defined to the new names from the start; see
xkbcommon/xkbcommon-compat.h). Namely, this will break binaries which:
1. Were compiled against a pre-stable version of libxkbcommon, and
2. Are linked against the next version of libxkbcommon, and
3. Expect to work.
This scenario is very unlikely, and will break in many other ways
anyway. Also, retaining support for these means including them in the
new symbol version file, which I would like to avoid.
Signed-off-by: Ran Benita <ran234@gmail.com>
If the keymap doesn't have any key-aliases (which is certainly
possible), the calloc(num_key_aliases, ...) is allowed to return NULL
according to the C standard, but this is not an error.
Signed-off-by: Ran Benita <ran234@gmail.com>
Virtual modifiers can have "mappings" to real modifiers, e.g. NumLock
may also set Mod2. In a normal turn of events, the various components
(depressed, latched, locked, and consequently effective) include the
mapped mods, because the masks are pre-resolved everywhere. However,
xkb_state_update_mask() accepts arbitrary mod masks, which may not be
resolved (if it comes from somewhere other than
xkb_state_serialize_mods()). So let's always resolve them ourselves.
Signed-off-by: Ran Benita <ran234@gmail.com>
It'd be nicer to use C11's static_assert(), but it's easier to roll our
own C99 version using a trick I saw in xv6.
Signed-off-by: Ran Benita <ran234@gmail.com>
There can be at most 16 vmods, and we rely on the facts that #vmods +
NUM_REAL_MODS (8) <= XKB_MAX_MODS (32) when accessing keymap->mods.mods.
But msb_pos() can potentially return up to #vmods = 32 if the server is
malicious, so we need to truncate it.
Signed-off-by: Ran Benita <ran234@gmail.com>
The first 8 modifiers in keymap->mods are the real modifiers; the virtual
modifiers are then at slots 8-24. But XkbGetMap's virtualMods mask
starts the virtual modifiers at zero, so we need to add an offset (like
we do correctly in get_vmod_names()).
https://github.com/xkbcommon/libxkbcommon/issues/9
Reported-by: @rtcm
Signed-off-by: Ran Benita <ran234@gmail.com>
With the following two rules:
InterpretDecl : INTERPRET InterpretMatch OBRACE
VarDeclList
CBRACE SEMI
{ $2->def = $4; $$ = $2; }
;
InterpretMatch : KeySym PLUS Expr
{ $$ = InterpCreate($1, $3); }
| KeySym
{ $$ = InterpCreate($1, NULL); }
;
And the fact that InterpCreate doesn't initialize ->def, if the
VarDeclList fails, the %destructor tries to recursively free the
uninitialized ->def VarDef. So always initialize it.
That was the only problematic code in the parser for %destructor (I'm
pretty sure).
Signed-off-by: Ran Benita <ran234@gmail.com>
If the parser has symbols on the stack, and then enters an error, it
discards the symbols and fails. But their actions which allocate AST
nodes had already ran. So we must free these to avoid leaks.
We use %destructor declarations, see
http://www.gnu.org/software/bison/manual/html_node/Destructor-Decl.html
Note: byacc only supports %destructor when compiled with
--enable-btyacc. Also, it doesn't support using the parse-param in the
destructor. So we might revert this commit before the next release, or
forget about byacc.
https://github.com/xkbcommon/libxkbcommon/issues/8
Signed-off-by: Ran Benita <ran234@gmail.com>
It's a name of a function in scanner-utils.h and also of some
parameters.
https://bugs.freedesktop.org/show_bug.cgi?id=79898
Reported-by: Bryce Harrington <b.harrington@samsung.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
If count % SIZE == 0 we did a useless iteration where start==stop. It's
harmless but strange, so don't do that.
Signed-off-by: Ran Benita <ran234@gmail.com>
matcher_match() builds up the kccgst's, and we steal the memory on
success. But on error we didn't free it.
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita