When xkb_free_keymap is called the atoms are all free'd, but action.c
keeps a global copy of interned "true" and "false", which remains stale.
The correct fix is to remove the need for the ActionsInit function
entirely.
Signed-off-by: Ran Benita <ran234@gmail.com>
These were several initializations that were forgotten in the previous
memory leak fixes.
Now several xkb_desc's can coexist (relatively) peacefully.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Only the atom.c is relevant with the new context API.]
The "makeit" variable is always true. Remove it and de-indent.
(Also change the type of the "len" variable to size_t to avoid some
useless casting).
Signed-off-by: Ran Benita <ran234@gmail.com>
The NULL check is unneeded, and prevented the atoms from being free'd.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb_map_unref.]
The new glibc (2.15) appear to cause trouble, particularly the sscanf
call, where makekeys will output empty hash tables. Using the appropriate
macros from inttypes.h makes it work again.
Signed-off-by: Ran Benita <ran234@gmail.com>
Such as:
Compiling path: ./test/data/bad.xkb mapName:
==1300== Conditional jump or move depends on uninitialised value(s)
==1300== at 0x4E46166: HandleVModDef (vmod.c:90)
==1300== by 0x4E3FEC9: HandleKeyTypesFile (keytypes.c:1035)
==1300== by 0x4E3FBE1: HandleIncludeKeyTypes.constprop.11 (keytypes.c:387)
==1300== by 0x4E401DD: HandleKeyTypesFile (keytypes.c:1022)
==1300== by 0x4E3FBE1: HandleIncludeKeyTypes.constprop.11 (keytypes.c:387)
==1300== by 0x4E401DD: HandleKeyTypesFile (keytypes.c:1022)
==1300== by 0x4E4026F: CompileKeyTypes (keytypes.c:1150)
==1300== by 0x4E3DF9B: CompileKeymap (keymap.c:169)
==1300== by 0x4E465E9: compile_keymap (xkbcomp.c:205)
==1300== by 0x4E46BE4: xkb_compile_keymap_from_file (xkbcomp.c:290)
==1300== by 0x400B37: test_file (filecomp.c:47)
==1300== by 0x4008E3: main (filecomp.c:90)
==1300== Uninitialised value was created by a stack allocation
==1300== at 0x4E3FB3F: HandleIncludeKeyTypes.constprop.11 (keytypes.c:366)
Signed-off-by: Ran Benita <ran234@gmail.com>
If we can't find the component of the include file we're looking for,
make sure we don't return success when we meant failure, segfault, or
spectacularly leak everything.
Tested with incorrect component includes for keycodes, compat, symbols,
and types.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reported-by: David Herrmann <dh.herrmann@googlemail.com>
Which also involved moving the global symbol map to be per-key instead;
this should probably be split out into a separate commit.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Instead of allowing only one keysym per level per group, do as the
external API indicates and allow multiples. The existing syntax is:
key <AD01> { [ q, Q ] };
where the new syntax is:
key <AD01> { [ q, Q, { H, E, L, L, O },
{ Y, E, S, space, T, H, I, S, space, I, S, space, D, O, G } };
to make the key in the extreme top left of the keyboard do pretty
surprising things in levels 3 and 4.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
All global state is removed from the parser and scanner.
This makes use of the standard facilities in Bison and Flex for
reentrant/pure scanner/lexer and location tracking.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated to current sources.]
Unify all the different Makefile.am into a single short top level one
(the test/Makefile.am file is left intact though).
This makes the build system simpler to look and should encourage
unifying more currently-disparate code.
Some further motivation can be found in this page:
http://www.flameeyes.eu/autotools-mythbuster/automake/nonrecursive.html
Signed-off-by: Ran Benita <ran234@gmail.com>
Since we have our own xkb_keysym_t type, it makes sense to have our own
NoSymbol value instead of the one from X11/X.h.
Signed-off-by: Ran Benita <ran234@gmail.com>
Since we define our own xkb_atom_t type, it makes sense not to use the
X11/X.h None value. This way we can also remove a lot of X11 includes.
Signed-off-by: Ran Benita <ran234@gmail.com>
i.e comparison of signed and unsigned values. These are mostly
harmless but fixing them allows to compile cleanly with -Wextra.
Signed-off-by: Ran Benita <ran234@gmail.com>
There are some cases where we must free a string with a const qualifier.
Add a macro UNCONSTIFY to trick the compiler into silencing the warning
in the cases where we know what we're doing.
Signed-off-by: Ran Benita <ran234@gmail.com>
And merge all the similar ones into the same name.
The u* prefix is chosen over the _Xkb prefix because it has more uses
throughout the codebase. But It should now be simple to choose a nice
prefix and stay consistent.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: fixed for the case where we have strcasecmp]
Some unused defines and geometry-removal leftovers (specifically the
file geom.c and the struct for the keyboard coordinates).
Signed-off-by: Ran Benita <ran234@gmail.com>
The recalloc function should be expressed in terms of bytes to match its
name. However uTypedRecalloc retains its type so nothing is changed.
Signed-off-by: Ran Benita <ran234@gmail.com>
Sorry if your libc doesn't have this, but it's not my problem.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reported-by: Ran Benita <ran234@gmail.com>
GCC complained:
misc.c:235:13: warning: logical 'and' of mutually exclusive tests is always false [-Wlogical-op]
misc.c:248:13: warning: logical 'and' of mutually exclusive tests is always false [-Wlogical-op]
Looking at keysymdef.h shows that the check is indeed wrong. This commit
updates the check to match the latin8 section of keysymdef exactly.
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
Daniel Stone
Guillem Jover