It only works if 'bison' or 'byacc' are provided, but sometimes byacc
is installed as plain 'yacc'. The check fails for that.
I broke this in bdd8c11, restore Daniel's retrospectively clever check.
Signed-off-by: Ran Benita <ran234@gmail.com>
First, make the rules and xkb scanners/parsers use the same logging
functions instead of rolling their own.
Second, use the gcc ##__VA_ARGS extension instead of dealing with C99
stupidity. I hope all relevant compilers support it.
Signed-off-by: Ran Benita <ran234@gmail.com>
Previously the early-exit codepath might have left some values
unexpanded, and we'd go looking for e.g "%l%(v)".
Signed-off-by: Ran Benita <ran234@gmail.com>
We want all the default logic in a test, so encapsulate it in this
function, and make all the get_default_* functions static.
Signed-off-by: Ran Benita <ran234@gmail.com>
There can be multiple include paths. But it's nicer in any case.
This also makes scanner_error actually use log_err instead of log_warn -
oops.
Signed-off-by: Ran Benita <ran234@gmail.com>
It returns XKB_LAYOUT_INVALID in case num_groups == 0. So we shouldn't
just save it in the state.
Note, though, that this condition is generally impossible.
Signed-off-by: Ran Benita <ran234@gmail.com>
Instead of thinking about signed <-> unsigned an whatnot.
bsearch() is inline in glibc, so gcc optimizes this away anyway.
Signed-off-by: Ran Benita <ran234@gmail.com>
The PLACEHOLDER was not meant to be used, but c++ doesn't like passing 0
to enums, so it was used. For this reason we add all the NO_FLAGS items,
so the PLACEHOLDER shouldn't be used anymore.
Second, XKB_MAP is the prefix we used ages ago, KEYMAP is the expected
prefix here. So deprecate that as well.
The old names may still be used through the xkbcommon-compat.h header,
which is included by default (no need to include directly).
Signed-off-by: Ran Benita <ran234@gmail.com>
Before:
ran@ran:~/src/libxkbcommon$ ./test/bench-key-proc
ran 20000000 iterations in 6.623018074s
After:
ran@ran:~/src/libxkbcommon$ ./test/bench-key-proc
ran 20000000 iterations in 4.762291091s
Not that anyone needs to process millions of keys per second...
Signed-off-by: Ran Benita <ran234@gmail.com>
It doesn't matter (I think), since the implicit conversion doesn't have
any effect (e.g. sign-extension). But it's better to be aware of the
type.
Signed-off-by: Ran Benita <ran234@gmail.com>
This reverts commit 1e6e5669c6.
It's probably safe, but let's not take any chances, as I don't have any
esoteric arch to test on. But keep the ATTR in case it's ever useful.
Signed-off-by: Ran Benita <ran234@gmail.com>
The int ones cannot be signed (they come as such from the scanner, and
NEGATE is never applied to them).
The uint32_t one is really an atom, but presumably the type was never
converted to xkb_atom_t.
Signed-off-by: Ran Benita <ran234@gmail.com>
size_t is too large; if we ever need it, that's the least of our
problems. Besides, when we roll our own (e.g. in keymap.h) it's already
unsigned int. Instead, add some emergency overflow check. So, why?
- It plays nicer with all the other uint32_t's and unsigned int's (no
extensions, etc.).
- Reduces keymap memory usage by 5% or so as a bonus.
Signed-off-by: Ran Benita <ran234@gmail.com>
Integer may be negative, so also need to test >= 0.
Also, $$ was left uninitialized if the keysym wasn't recognized.
Signed-off-by: Ran Benita <ran234@gmail.com>
We have quite diverged from the upstream file, so let's make it at least
easier to look at. Remove some unused macros and rename some for
consistency.
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita