| Age | Commit message (Collapse) | Author |
|---|
|
No point spending 3 lines on this, especially given that this warning is
always triggered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
This warning will be triggered all the time now that xkeyboard-config has
started adding keycodes > 255. Downgrade to an info, there's nothing the user
can do about this warning anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Those macros date back to when varargs weren't a thing but they've
been #defined to the same value for 17 years now.
Patch generated with:
for action in WARN INFO ERROR ACTION FATAL WSGO; do
sed -i "s/${action}[1-9]/${action}/g" `git ls-files`
done
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Let's clean this up so I don't have to fight vim and git in removing them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Found by using:
codespell --builtin clear,rare,usage,informal,code,names
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
We expect evdev to have keycodes above 255, there's no reason to warn
about this.
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Continuation from 7fdfabd75 "keycodes: Ignore high keycodes"
A keymap with a key > 255 will have a xkb_keycodes.maximum of that keycode.
Let's not throw a fatal error on that, just crop it back to the maximum of
255. This doesn't set the "high_keycode_warned" on purpose so we get this for
the first key that actually matters.
Reproducible with xkeyboard-config 2.24 which has a maximum of 374.
https://bugzilla.redhat.com/show_bug.cgi?id=1587998
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
|
|
Rather than throwing a fatal error when a keycode definition exceeds the
declared maximum (i.e. 255), just ignore the definition and continue.
This allows xkeyboard-config to start shipping datasets including high
keycodes, which will work in xkbcommon as it ignores explicit range
declarations.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reported-by: Christian Kellner <gicmo@gnome.org>
|
|
Flagged by cppcheck 1.64:
[app/xkbcomp/keycodes.c:264] -> [app/xkbcomp/keycodes.c:262]:
(warning) Possible null pointer dereference: new - otherwise it
is redundant to check it against null.
[app/xkbcomp/keytypes.c:600] -> [app/xkbcomp/keytypes.c:597]:
(warning) Possible null pointer dereference: old - 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>
|
|
It was right too: printf was being misused in some spots.
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.
|
|
|
|
|
|
What use is a handler if we only ever use one function anyway?
|
|
|
|
"Conditional jump or move depends on uninitialised value(s)"
|
|
|
|
|
|
indent -cbi 0 -nprs -nut -npcs -i4 -bli 0 *.c *.h
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
