If the parser has symbols on the stack, and then enters an error, it
discards the symbols and fails. But their actions which allocate AST
nodes had already ran. So we must free these to avoid leaks.
We use %destructor declarations, see
http://www.gnu.org/software/bison/manual/html_node/Destructor-Decl.html
Note: byacc only supports %destructor when compiled with
--enable-btyacc. Also, it doesn't support using the parse-param in the
destructor. So we might revert this commit before the next release, or
forget about byacc.
https://github.com/xkbcommon/libxkbcommon/issues/8
Signed-off-by: Ran Benita <ran234@gmail.com>
We didn't really have any. It also a exposes a memory leak, since the
parser doesn't clean up the AST nodes of the discarded symbols.
Signed-off-by: Ran Benita <ran234@gmail.com>
It's a name of a function in scanner-utils.h and also of some
parameters.
https://bugs.freedesktop.org/show_bug.cgi?id=79898
Reported-by: Bryce Harrington <b.harrington@samsung.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
If count % SIZE == 0 we did a useless iteration where start==stop. It's
harmless but strange, so don't do that.
Signed-off-by: Ran Benita <ran234@gmail.com>
matcher_match() builds up the kccgst's, and we steal the memory on
success. But on error we didn't free it.
Signed-off-by: Ran Benita <ran234@gmail.com>
Two problems:
- `j` can be >= `SIZE`, and needs to be wrapped like in the rest of the
code.
- `cookies[j % SIZE]` is not initialized if there's no atom in `from[j]`.
The is manifested when:
- We've already gone through one batch (>= 128 atoms) (in fact this
cannot happen in call to `adopt_atoms` in the current code).
- An XCB request failed in the middle of a batch.
Signed-off-by: Ran Benita <ran234@gmail.com>
Instead just statically allocate the mods array (of size MAX_MOD_SIZE =
32). The limit is not going anywhere, and static allocations are nicer
(nicer code, no OOM, etc.). It's also small and dense enough.
Signed-off-by: Ran Benita <ran234@gmail.com>
The keymap is not removed entirely from the Info (just constified),
since it is still needed in AddKeySymbols() for looking up aliases. This
dependency will be removed in the future.
Signed-off-by: Ran Benita <ran234@gmail.com>
This is the only place where the modifier information is modified. We
will make it local to a given XKB file (after which it will be merged
into the keymap). Currently it changes the keymap directly, which
sidesteps the abstraction and leaves side-effects even if the XkbFile's
compilation fails.
Signed-off-by: Ran Benita <ran234@gmail.com>
The modifier printing functions only need the modifier information, they
don't care about keys or leds, etc.
Signed-off-by: Ran Benita <ran234@gmail.com>
The only thing that the compilation phase needs the keymap for currently
is for access to the modifier information (it also modifies it in
place!). We want to only pass along the neccessary information, to make
it more tractable and testable, so instead of passing the entire keymap
we add a new 'mod_set' object and pass a (const) reference to that.
The new object is just the old array of 'struct xkb_mod'.
Signed-off-by: Ran Benita <ran234@gmail.com>
Separate the ctx object to its own field in CompatInfo, instead of doing
keymap->ctx.
The compilation functions should not have direct access to the keymap;
instead they should process the files with their own independent state
(in the *Info structs) as much as possible, and only at the end should
they be copied (i.e. commited) to the keymap. If the compilation fails,
it leaves no by-products. It's also just good form.
This was seemingly the original author's intention, but I suppose he cut
a few corners (mostly with the handling of virtual modifiers, which are
threaded through types -> compat -> symbols).
This commit is the first step and may look artificial; however the
'keymap' field will be removed shortly.
Signed-off-by: Ran Benita <ran234@gmail.com>
The documentation should be clear about what is happening, even if it's
rather unlikely anyone will really dig into the details.
Signed-off-by: Ran Benita <ran234@gmail.com>
And also add release dates to the NEWS.
We're adding API freely, so this can make life easier for anyone who
wants to stay compatible with an older version.
Signed-off-by: Ran Benita <ran234@gmail.com>
This CI service https://travis-ci.org/ builds the project in several
configurations, runs the tests, and if something fails it sends an email.
Testing on some other systems is always good, and there don't seem to
be any drawbacks to this, so why not.
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita