Fix all reported null dereferences from clang-analyzer.
There seems to be one false negative (in file indicators.c), but it is
fixed anyway.
Signed-off-by: Ran Benita <ran234@gmail.com>
Every caller did the exact same check on the group bounds after calling
ExprResolveGroup, so might as well do it inside.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
We never want to solely lookup a virtual modifier without also looking
up core modifiers. So, rather than chaining the vmod lookup inside the
core modifier lookup, invert the ordering.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
None of the lookup functions anyone ever used supported field
references, so don't pretend we do in the API.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
groupNames was declared in compat.c as a global to anything which
included compat.h (for which groupNames was its sole reason to exist),
but only ever used in indicators.c.
Which is kind of fortunate, given that e314931e removed identical
definitions of groupNames (as integers, not masks) from both action.c
and symbols.c.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Move the bulk of ExprResolveInteger into an internal function called
ExprResolveIntegerLookup, and introduce ExprResolveInteger as a simple
wrapper which doesn't take priv/lookup arguments.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Because, joke's on you, it wasn't actually looking up radio groups.
Just checking to see if it was a string that was "none", or an integer.
Lord give me strength.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Which is just a slightly more typesafe wrapper around the chained
ExprResolveModMask everyone was using earlier.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Make sure we carry over an explicit minimum/maximum keycode setting,
rather than just using the computed minimum/maximum; this got broken
while changing the keycode range to be unsigned.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reported-by: Pekka Paalanen <ppaalanen@gmail.com>
Thanks to autotools happily building stale generated sources, I hadn't
actually ever built my xkbparse.y changes. Fix that so it not only
compiles, but works. This seems to parse long keycodes correctly,
although I very much would not recommend testing this by declaring
0x1fffffff as your highest keycode.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
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>
This reverts commit bf9fdceef6.
We really only want to expose symbols that we explicitly mark as part of
the API. This may not work with other platforms or compilers, but the
fact that private symbols are not available on Linux+GCC is enough of an
incentive to not use those.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
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>
Ran Benita
Daniel Stone
Rob Bradford
Pekka Paalanen
Cyril Brulebois
Kristian Høgsberg