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`.
For the sake of compatibility, this reintroduce some deleted keysyms and
postpone the effective deprecation of others.
xorgproto commit: fe12c5102762afcbf852e50dcbbdea2ef625570c
Also added tests for some canonical names.
An empty element is allowed in SymbolsBody definition, so the following
keymap is gramatically correct.
```
xkb_keymap {
...
xkb_symbols "sym" {
key <SPC> {, [Space] };
};
};
```
However, the current parser crashes with the keymap due to null pointer
access.
This change fixes it by changing the parser not to allow it.
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.
Fixed the upper case mappings for:
- XKB_KEY_ydiaeresis
- XKB_KEY_mu
- XKB_KEY_ssharp
Note: In Unicode, the upper case of “ß” (U+00DF) is *not* “ẞ” (U+1E9E)
but “SS”. “ẞ” is reserved for text in capitals.
Currently `xkb_keysym_is_modifier` does not detect the following keysyms:
- `XKB_KEY_ISO_Level5_Shift`
- `XKB_KEY_ISO_Level5_Latch`
- `XKB_KEY_ISO_Level5_Lock`
Indeed, there is a mistake in the keysym interval that the code checks.
The reason seems a confusing order of the keysyms in
`xkbcommon-keysyms.h`: the current code has a comment “libX11 only goes
up to XKB_KEY_ISO_Level5_Lock”, but in fact the modifiers keysyms are
listed in a _semantic_ order in `xkbcommon-keysyms.h`, not in the
increasing keysym _value_ order.
Fixed by using the same (correct) code as libX11 and added some tests.
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`.
Add an efficient way to iterate over the assigned keysyms.
Currently only provided for testing, so we guard it by
`ENABLE_PRIVATE_APIS` in order to reduce the installed library.
Currently there is no direct way to know the minimum and maximum keysym
values that are assigned, i.e. that have an explicit name or are
Unicode keysyms.
Introduce the new following internal API:
- XKB_KEYSYM_MIN_ASSIGNED
- XKB_KEYSYM_MAX_ASSIGNED
- XKB_KEYSYM_MIN_EXPLICIT
- XKB_KEYSYM_MAX_EXPLICIT
- XKB_KEYSYM_COUNT_EXPLICIT
Also add a bunch of tests to ensure consistant keysyms bounds.
Add excerpt of `util-mem.h` from libei defining the macro `steal`, in
order to improve memory management and the code semantics.
See: 38132d6fc5/src/util-mem.h (L92)
Previously the attribute “popularity” was completely ignored. It also
did not respect the modified DTD, because its default value depends if
we are currently parsing an “extras” rules file.
Fixed:
- Always parse the popularity attribute.
- Change the DTD to reflect that the default value is implied.
- Add check for recursive includes of keymap components. It relies on
limiting the include depth. The threshold is currently to 15, which
seems reasonable with plenty of margin for keymaps in the wild.
- Add corresponding new log message `recursive-include`.
- Add tests for recursive includes.
The string `buf` was not freed after each call to `asprintf_safe`.
Avoid allocating and introduce the new message: `XKB_ERROR_INSUFFICIENT_BUFFER_SIZE`.
When there is no error the types are “stolen” and copied to the keymap.
But when there is an error, `MergeIncludedKeyTypes` just return without
“stealing” nor freeing the types.
Fixed by explicitly freeing the key types.
Fixed another leak in `HandleKeyTypeDef` that may occur if there is an
error in parsing a type definition.
GCC 14 introduces a new -Walloc-size included in -Wextra which gives:
```
src/state.c:589:9: warning: allocation of insufficient size ‘1’ for type ‘struct xkb_state’ with size ‘128’ [-Walloc-size]
```
The calloc prototype is:
```
void *calloc(size_t nmemb, size_t size);
```
So, just swap the number of members and size arguments to match the prototype, as
we're initialising 1 struct of size `sizeof(struct xkb_state)`. GCC then sees we're not
doing anything wrong.
Signed-off-by: Sam James <sam@gentoo.org>
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.
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.
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 handling of keysym name guards (e.g. `#ifndef XK_Ydiaeresis`) was
incomplete and led to a missing keysym.
Make `sripts/makeheader` more robust to C macros handling.
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>
Previously we had two types of macros for logging: with and without
message code. They were intended to be merged afterwards.
The idea is to use a special code – `XKB_LOG_MESSAGE_NO_ID = 0` – that
should *not* be displayed. But we would like to avoid checking this
special code at run time. This is achieved using macro tricks; they
are detailed in the code (see: `PREPEND_MESSAGE_ID`).
Now it is also easier to spot the remaining undocumented log entries:
just search `XKB_LOG_MESSAGE_NO_ID`.
Usually it is better to use the corresponding human-friendly keysym
names. If there is none, then the keysym is most probably not
supported in the ecosystem. The only use case I see is similar to the
PUA in Unicode (see: https://en.wikipedia.org/wiki/Private_Use_Areas).
I am not aware of examples of this kind of use.
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
In `parser.y`, a numeric keysym is parsed by formatting it in its
hexadecimal form then parsed as a keysym name. This is convoluted.
Fixed by checking directly the upper bound.
When parsing hexadecimal keysym using `xkb_keysym_from_name`,
the result is limited by `parse_keysym_hex` to 0xffffffff, but the
maximum keysym is XKB_MAX_KEYSYM, i.e. 0x1fffffff.
Fixed by adding an upper bound.
Keysyms are 32-bit integers with the 3 most significant bits always set
to zero. See: Appendix A “KEYSYM Encoding” of the X Window System
Protocol at https://www.x.org/releases/current/doc/xproto/x11protocol.html#keysym_encoding.
Add a new constants XKB_KEYSYM_MIN and XKB_KEYSYM_MAX to make the
interval of valid keysyms more obvious in the code.
In commit 1638409b22, the number of
compose nodes was limited to 65535 to enable "future optimizations",
which apparently means slightly reduced memory usage due to fitting in
a uint16_t. At this time, it was mentioned that the author was not
aware of "any compose files which come close".
However, I'm one of the users that actually do require a larger number
of nodes for their compose file. Thus, use a uint32_t again and raise
the limit significantly.
Mikhail Gusarov
Pierre Le Marre
Yuichiro Hanada
Sam James
Ran Benita
M Kelly
alois31