| Age | Commit message (Collapse) | Author |
|---|
|
I can not find any point in our git history at which alloca() or the
Xalloca.h macros ALLOCATE_LOCAL() & DEALLOCATE_LOCAL() were actually
used in this source file.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
There is no need to ensure the pointers passed to free are not NULL,
especially right after passing them to strncpy without checking for
NULL.
Flagged by cppcheck 1.64:
[app/xkbcomp/parseutils.c:557] -> [app/xkbcomp/parseutils.c:559]:
(warning) Possible null pointer dereference: over - otherwise it
is redundant to check it against null.
[app/xkbcomp/parseutils.c:558] -> [app/xkbcomp/parseutils.c:561]:
(warning) Possible null pointer dereference: under - otherwise it
is redundant to check it against null.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
|
|
When we opened a new file after encountering a parse error, we weren't
resetting our scan state, and continued to read out of the old buffer
rather than that of the new file.
Fixes a regression introduced in 9887842e ('Use fread() instead of
getc()').
Test case:
xkbcomp -lfhlpR "path/to/xkeyboard-config.git/symbols/*"
The Makefiles in that tree would cause parse errors, the resulting directory
file is incomplete (down from ~12000 to ~230 lines).
Reported-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
|
|
Brown paper bag in full effect.
The previous fix, while crushing the previous problem where an unknown
keysym for an interp def would lead to every key matching it, also
ignored explicit Any+AnyOfOrNone(All) mappings.
Such as the one xkeyboard-config relied on for Control to actually
update the modifier state.
Fix this by allowing mappings explicitly declared as Any/NoSymbol, while
ignoring only those with failed keysym lookups. Unfortunately, due to
the structure of the parser, it's a deeply inelegant fix.
Verified with a quick check of all layouts (albeit using default
variants only) in xkeyboard-config that this results in no changes to
the output at all, compared to xkbcomp 1.1.1.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
Alan Coopersmith pointed out that C89 mandates limits.h, so for once in
X's life, checking for a system header is just being unnecessarily
paranoid.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
Raw keysyms were not getting parsed correctly, due to forgetting to add
the code to libX11, forgetting to add the backwards-compat code for old
libX11s, and then stuffing the lexing up anyway. Yeesh.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
Instead of calling XStringToKeysym on every keysym we parse, store it as
a string until we need to store it in an actual keymap.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
Remaining warnings are due to macros that check address or vectors
on the stack and auto generated yacc code.
Compiled with default flags and also as:
% make CFLAGS=-DENTRY_TRACKING_ON -DDEBUG_ON -DASSERTIONS_ON
to ensure the "simplification" of code like:
foo.c:
<hash>define DEBUG_VAR foo_VAR
<hash>include "foo.h"
...
foo.h:
<hash>ifdef DEBUG_VAR_NOT_LOCAL
extern
<hash>endif
int DEBUG_VAR;
...
did not change the author's "intended" logic.
|
|
indent -cbi 0 -nprs -nut -npcs -i4 -bli 0 *.c *.h
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
