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 is like test/stringcomp, only instead of using
xkb_keymap_new_from_string(), it uses xkbcomp to upload the keymap to a
dummy Xvfb X server and then xkb_x11_keymap_new_from_device().
If any of these components are not present or fails, the test is shown
as skipped.
The test is messy, fragile, limited and depends on external tools, but I
will improve on that later -- it's better to have a test.
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>
We didn't really have any. It also a exposes a memory leak, since the
parser doesn't clean up the AST nodes of the discarded symbols.
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>
Two problems:
- `j` can be >= `SIZE`, and needs to be wrapped like in the rest of the
code.
- `cookies[j % SIZE]` is not initialized if there's no atom in `from[j]`.
The is manifested when:
- We've already gone through one batch (>= 128 atoms) (in fact this
cannot happen in call to `adopt_atoms` in the current code).
- An XCB request failed in the middle of a batch.
Signed-off-by: Ran Benita <ran234@gmail.com>
Instead just statically allocate the mods array (of size MAX_MOD_SIZE =
32). The limit is not going anywhere, and static allocations are nicer
(nicer code, no OOM, etc.). It's also small and dense enough.
Signed-off-by: Ran Benita <ran234@gmail.com>
The keymap is not removed entirely from the Info (just constified),
since it is still needed in AddKeySymbols() for looking up aliases. This
dependency will be removed in the future.
Signed-off-by: Ran Benita <ran234@gmail.com>
This is the only place where the modifier information is modified. We
will make it local to a given XKB file (after which it will be merged
into the keymap). Currently it changes the keymap directly, which
sidesteps the abstraction and leaves side-effects even if the XkbFile's
compilation fails.
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita