Currently we do not check that the Compose files we try successively are
*regular* files. This may result in an error, while we should just really
just skip the corresponding path.
Fixed by adding the new utily function `open_file`.
The current `xkb_compose_table_iterator_next` segfaults when used with an
empty table. Indeed, in this case we initialize cursors in
`xkb_compose_table_iterator_new` with the dummy node and the direction
`NODE_LEFT`, but the dummy node is a leaf!
Fixed by initializing with no cursors when the table is has no non-dummy
nodes.
Currently there is no indication of the maximum length of keysym names.
This is statically known, so add the new *internal* following API:
`XKB_KEYSYM_NAME_MAX_SIZE`.
Leading BOM is legal and is used as a signature — an indication that
an otherwise unmarked text file is in UTF-8.
See: https://www.unicode.org/faq/utf_bom.html#bom5 for further details.
The octal parser accepts the range `\1..\777`. The result is cast to
`char` which will silently overflow.
This commit prevents overlow and will treat `\400..\777` as invalid
escape sequences.
NULL usually terminates the strings; allowing to produce it via escape
sequences may lead to undefined behaviour.
- Make NULL escape sequences (e.g. `\0` and `\x0`) invalid.
- Add corresponding test.
- Introduce the new message: XKB_WARNING_INVALID_ESCAPE_SEQUENCE.
Allow users to iterate the entries in a compose table. This is useful
for other projects which want programmable access to the sequences,
without having to write their own parser.
- New API:
- `xkb_compose_table_entry_sequence`;
- `xkb_compose_table_entry_keysym`;
- `xkb_compose_table_entry_utf8`;
- `xkb_compose_table_iterator_new`;
- `xkb_compose_table_iterator_free`;
- `xkb_compose_table_iterator_next`.
- Add tests in `test/compose.c`.
- Add benchmark for compose traversal.
- `tools/compose.c`:
- Print entries instead of just validating them.
- Add `--file` option.
- TODO: make this tool part of the xkbcli commands.
Co-authored-by: Pierre Le Marre <dev@wismill.eu>
Co-authored-by: Ran Benita <ran@unusedvar.com>
Signed-off-by: Ran Benita <ran@unusedvar.com>
The test `test_from_locale` fails when there is a user-defined compose
file, e.g. ~/.XCompose.
Indeed, the function `xkb_compose_table_new_from_locale` use various
environment variables to determine the location of the compose file.
Ensure no environment variables but the required ones are set, in order
to have robust tests.
lokid and hikid actually stores the sibling to current node, which
should not be cleared when override. This would break the sequence with
a common prefix when override another.
Fix#286
Signed-off-by: Weng Xuetian <wengxt@gmail.com>
We only ever care about whether we error out or not, so let's wrap this into
something more sane.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously we included it with an `-include` compiler directive. But
that's not portable. And it's better to be explicit anyway.
Every .c file should have `include "config.h"` first thing.
Signed-off-by: Ran Benita <ran@unusedvar.com>
Some results from the benchmark (compilation of en_US.UTF-8/Compose):
$ grep 'model name' /proc/cpuinfo
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
$ uname -a
Linux ran 3.16.1-1-ARCH #1 SMP PREEMPT Thu Aug 14 07:40:19 CEST 2014 x86_64 GNU/Linux
$ ./test/compose bench
compiled 1000 compose tables in 7.776488331s
So according to the above benchmark and valgrind --tool=massif, an
xkb_compose_table adds an overhead of about ~8ms time and ~130KB
resident memory.
For contrast, a plain US keymap adds an overhead of ~3ms time and 90KB
resident memory.
Signed-off-by: Ran Benita <ran234@gmail.com>
Pierre Le Marre
Ran Benita
Weng Xuetian
Peter Hutterer
Ran Benita