Some error paths don't set info->xkb correctly, so just do like most
utility functions and pass the xkb_desc explicitly.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
And use it consistently everywhere, including with a special long-safe
internal keycode type, to ease the transition to large keycodes.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
For some reason, lex decided to reduce a strcpy into an assignment,
leading to entirely justified valgrind warnings about invalid reads,
when scanFile was set to a string which may have only ever lived on the
stack of a now-exited function.
Make it a strdup() instead.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Some routes through HandleGeometryVar do not set a return value. Set a default
value for the return variable to avoid returning an uninitialised value.
Which just calls XkbcFreeKeyboard with the only arguments you'd ever
pass it.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Avoids assigning the global pointer to a value that may only have a stack
lifetime:
Fixes valgrind warnings such as:
==24795== Invalid read of size 1
==24795== at 0x4A06E9A: strcpy (mc_replace_strmem.c:311)
==24795== by 0x4E54D68: ProcessIncludeFile (misc.c:73)
==24795== by 0x4E59726: HandleIncludeSymbols.constprop.3 (symbols.c:829)
==24795== by 0x4E59D8E: HandleSymbolsFile (symbols.c:1673)
==24795== by 0x4E5A068: CompileSymbols (symbols.c:2211)
==24795== by 0x4E51A61: CompileKeymap (keymap.c:155)
==24795== by 0x4E5B410: xkb_compile_keymap_from_components (xkbcomp.c:236)
==24795== by 0x4E5B587: xkb_compile_keymap_from_rules (xkbcomp.c:161)
==24795== by 0x405ED2: display_create (window.c:2007)
==24795== by 0x403732: main (desktop-shell.c:320)
==24795== Address 0x7fefff0a0 is just below the stack ptr. To suppress, use:
--workaround-gcc296-bugs=yes
==24795==
==24795== Source and destination overlap in strcpy(0x7fefff430, 0x7fefff430)
==24795== at 0x4A06F3D: strcpy (mc_replace_strmem.c:311)
==24795== by 0x4E54D68: ProcessIncludeFile (misc.c:73)
==24795== by 0x4E59726: HandleIncludeSymbols.constprop.3 (symbols.c:829)
==24795== by 0x4E59D8E: HandleSymbolsFile (symbols.c:1673)
==24795== by 0x4E5A068: CompileSymbols (symbols.c:2211)
==24795== by 0x4E51A61: CompileKeymap (keymap.c:155)
==24795== by 0x4E5B410: xkb_compile_keymap_from_components (xkbcomp.c:236)
==24795== by 0x4E5B587: xkb_compile_keymap_from_rules (xkbcomp.c:161)
==24795== by 0x405ED2: display_create (window.c:2007)
==24795== by 0x403732: main (desktop-shell.c:320)
Those warnings disappear accordingly:
| CC parseutils.lo
| parseutils.c:742: warning: no previous prototype for ‘CheckDefaultMap’
| CC xkbscan.lo
| xkbscan.l: In function ‘XKBParseString’:
| xkbscan.l:220: warning: implicit declaration of function ‘CheckDefaultMap’
| xkbscan.l:220: warning: nested extern declaration of ‘CheckDefaultMap’
Reviewed-by: Dirk Wallenstein <halsmit@t-online.de>
Signed-off-by: Cyril Brulebois <kibi@debian.org>
There's no need for this xlib include:
| YACC xkbparse.c
| CC xkbparse.lo
| xkbparse.y:98:22: error: X11/Xlib.h: No such file or directory
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
This would cover the scenario where these headers file are updated,
for example, a new version is installed. Running 'make' again
on libxkbcommon should rebuild ks_tables.h.
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
This program is a utility to generated a header file.
The header file it generates should not be located in the
directory where this utility program is compiled.
Move the /makekeys dir as a sibling of /src.
This reduces the number of bi-directional relationships
between directories.
Make corresponding makefiles simplifications.
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
These automake variables are not currently used.
The variable KS_HEADERS is not required anymore.
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
BUILT_SOURCES and MAINTAINERCLEAN are not needed for lex and yacc
Note that xkbscan was missing on those lines.
Automake generates all the rules to handle building, distribution
and cleaning.
Acked-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Fixes automake warning.
Acked-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
xkbscan.l: In function 'setScanState':
xkbscan.l:201:1: warning: control reaches end of non-void function
I: Program returns random data in a function
E: libxkbcommon no-return-in-nonvoid-function xkbscan.l:201
Change return type of setScanState to void, since a return value is
never used by its callers.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Use -no-undefined to assure libtool that the libxkbcommon library has
no unresolved symbols at link time, so that libtool will build a shared
library on platforms require that all symbols are resolved when the
library is linked.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Keep the parsed form of the last-used rules file around, and reuse that
if we get asked for the same ruleset. If not, bin it and cache the
other one.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Use CARD32 instead of Atom/KeySym/et al to avoid type size confusion
between server and non-server code; relatedly, move the geometry headers
in from kbproto, so every non-simple type (i.e. structs containing
nothing more than basic types) is now copied into xkbcommon.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Allow people to plug in an external atom database (e.g. the X server's),
so we don't have to migrate our own atoms over later. We are a bit
over-keen on atoms at the moment, so it does pollute the atom database a
bit though.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
On 64-bit architectures, XID varies in size between the server (always
32 bits), and non-server (always unsigned long) for some inexplicable
reason. Use CARD32 instead to avoid this horrible trap.
This involves dragging in XkbClientMapRec so we don't get stuck in the
KeySym trap.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>