kc3-lang/libxkbcommon/src

src

Log

Author Commit Date CI Message
Pierre Le Marre 39c1bb36 2025-03-29T17:47:31 xkbcomp: Fix static_assert syntax
Pierre Le Marre d2f7b9cd 2025-04-04T17:29:35 rules: Do not use strto* parsers
Pierre Le Marre d5a91fa9 2025-04-04T16:38:16 xkbcomp: Use custom parsers instead of strtol* The use of `strtol*` functions was already restricted due to its slowness and its capacity to parse other stuff than digits (e.g. signs and spaces). There is also another *big* limitation: it requires a NULL-terminated string. This is incompatible with our functions that work on buffers, because we cannot guarantee this. This may lead to a memory violation if the last token is a number. We now roll out our own parsers, which are more efficients and compatible with buffers.
Pierre Le Marre 8594adc4 2025-03-31T13:52:36 doc: Mention that `alternate` merge mode is not supported
Pierre Le Marre 44480f7c 2025-04-01T08:28:02 xkbcomp: Enable lists of keysyms and actions {} and {a} Motivations: - Follow the principle of least astonishment; - Ensure consistency; - Enhance the use of custom defaults; - Facilitate the tests. There is some ambiguity because we use `{}` to denote both an empty list of keysyms and an empty list of actions. But as soon as we get a keysym or an action, we know whether it is a `MultiKeySymList` or a `MultiActionList`. So we just count the `{}` at the *beginning* using `NoSymbolOrActionList`, then replace it by the relevant count of `NoSymbol` or `NoAction()` once the ambiguity is solved. If not, this is a list of empties of *some* type: we drop those empties and delegate the type resolution using `ExprEmptyList()`.
Pierre Le Marre 36bb4fe3 2025-04-02T19:10:02 xkbcomp: Minor renaming Use the same case for `KeySym` in the parser.
Pierre Le Marre e09cbe66 2025-04-02T10:46:06 symbols: Fix handling of empty keys Before this commit, the following symbols: ```c xkb_symbols { virtual_modifiers M1, M2; key <A> {}; key <B> { [] }; key.vmods = M1; key <C> {}; key <D> { vmods = M2 }; }; ``` would be equivalent to: ```c xkb_symbols { virtual_modifiers M1,M2; key <B> { [ NoSymbol ] }; }; ``` `<B>` entry could be skipped but is harmless. However, `<C>` and `<D>` are missing, which would lead to the mapping resolution of `M1` and `M2` failing. After this commit, it is equivalent to: ```c virtual_modifiers M1,M2; key <C> { vmods = M1 }; key <D> { vmods = M2 }; ``` Empty keys are skipped entirely, but any explicit field: - is taken into account: previously they would be skipped if there were no group; - forces the key to be printed at serialization.
Pierre Le Marre 2e0245f8 2025-04-02T10:45:44 xkbcomp: Enable more empty lists - Empty `interpret` - Empty key `type` - Empty `indicator` Motivations: - Follow the principle of least astonishment; - Ensure consistency; - Enhance the use of custom defaults; - Facilitate the tests.
Pierre Le Marre 6881fb32 2025-04-01T08:28:02 xkbcomp: Drop trailing NoSymbol and NoAction() This brings us closer to what `xkbcomp` outputs. One should use the explicit `VoidSymbol` instead of `NoSymbol`, in order to avoid dropping empty levels. This may affect keys that rely on an *implicit* key type. Example: - Input: ```c key <> { [a, A, NoSymbol] }; ``` - Compilation with xkbcommon \< 1.9.0: ```c key <> { type= "FOUR_LEVEL_SEMIALPHABETIC", [a, A, NoSymbol, NoSymbol] }; ``` - Compilation with xkbcommon ≥ 1.9.0: ```c key <> { type= "ALPHABETIC", [a, A] }; ```
Pierre Le Marre 7dbd2576 2025-04-01T19:20:10 keymap: Use constants for Lock and Control indexes These indexes are fixed, so there is no need to lookup their name.
Pierre Le Marre 55e99f0a 2025-04-01T09:03:25 keymap: refactor ClearLevelInfo
Pierre Le Marre 8ba5c453 2025-03-30T10:07:10 xkbcomp: Use section reference as default section name Before this commit the following keymap: ```c xkb_keymap { xkb_keycode {}; }; ``` would result in (boilerplate removed): ```c xkb_keymap { xkb_keycode "(unnamed)" {}; }; ``` This is both useless and wasting allocation: section names are optional, so we should just remove this default name altogether and keep it undefined, as in the original keymap. The situation is a bit different if there is an include, as for keymaps created from RMLVO names. Before this commit, the following keymap: ```c xkb_keymap { xkb_keycode { include "evdev+aliases(qwerty)" }; }; ``` would result in (boilerplate removed): ```c xkb_keymap { xkb_keycode "(unnamed)" { … }; }; ``` With this commit we now follow the Xorg xkbcomp style by using the section reference (the include string) as the *default* section name. So the previous example would now result in: ```c xkb_keymap { xkb_keycode "evdev_aliases(qwerty)" { … }; }; ``` which is useful to give a hint of the original include. Note that if the original section had a name, it would preserve it: ```c xkb_keymap { xkb_keycode "test" { include "evdev+aliases(qwerty)" }; }; ``` would compile to: ```c xkb_keymap { xkb_keycode "test" { … }; }; ```
Pierre Le Marre 3150bca8 2025-03-30T09:54:02 xkbcomp: Make all components optional We already accept *empty* components, such as: `xkb_compat {};`. Let’s accept missing components as well, so that we can reduce the boilerplate in our tests. Note that we will still explicitly serialize empty components for compatibility with previous xkbcommon versions and Xorg xkbcomp.
Pierre Le Marre 23598fa1 2025-03-25T22:52:06 Enable merge mode “replace” in include statements Previously only the merge modes “override” and “augment” were available in include statements, using the prefix ‘+’ and ‘|’ respectively. While on one hand `replace` include statement can be used in keymap files, on the other hand *rules* files have no way to express the *replace* mode. This commit enables the merge mode “replace” using the prefix `^`. This prefix was chosen due to its similarity with the `XOR` bit operator, which convey *mutual exclusion*. Other candidates: - `!` conveys some kind of higher precedence, akin to CSS `!important`. But it conflicts with the section header `!`, which is a token in the current parser. It would require special handling, not worth it. It also convey the meaning of negation, which is confusing. - `&` has the advantage of not corresponding to a token in the rules parser. `^` seems however to stand out more and it is less likely to trigger erroneous comparison with `|` and `&` bit operators.
Pierre Le Marre 6fc6e64b 2025-03-26T10:35:22 rules: Added extended wild cards <none>, <some> and <any> Added the following wild cards to the rules file syntax, in addition to the current `*` legacy wild card: - `<none>`: Match *empty* value. - `<some>`: Match *non-empty* value. - `<any>`: Match *any* (optionally empty) value. Its behavior does not depend on the context, contrary to the legacy wild card `*`. This will enable writing much simpler rules, see [!764] for an example of tricky rules in the `xkeyboard-config` project, that would benefit from the new wild cards. [!764]: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/merge_requests/764 The verbose wild cards are preferred to single characters: - More intuitive: self-explanatory. - Does not steal syntax from other token. - Extensible syntax, should we need it. A previous proposal used the characters (`!`, `+`, `?`) for their similarity with the corresponding syntax of regular expressions (negative assertion & quantifiers), in line with `*`. But `!` is not that intuitive after all and conflict with its role as section header. Furthermore, `+` is also used as a merge mode. Finally, nothing beats whole short words for readability.
Pierre Le Marre 500b260b 2025-03-28T09:38:58 xkbcomp: Fix parser failure on floating-point numbers Before this commit we used `strtold`, which depends on the locale. But the XKB syntax is fixed and uses a period as decimal separator. So ensure the syntax is correct without relying on `strtold` and truncate the result, as the parser does not use floating-point numbers.
Pierre Le Marre d7e112fe 2025-03-29T19:44:13 registry: Added support for libxml2 2.14+ `libxml2-2.14+` now disallows parsing trailing `NULL` bytes, so don’t. This is backward-compatible with previous versions of the library.
Pierre Le Marre cc95f217 2025-03-25T11:15:45 xkbcomp: Fix whichGroupState serialization This indicator field was previously looked up in the wrong table, resulting the erroneous serialization `(null)`.
Pierre Le Marre 9a5547ce 2025-03-28T11:01:18 symbols: Fix leak in HandleSymbolsDef
Pierre Le Marre 8e92f25e 2025-03-13T21:26:59 rules: Added xkb_components_names_from_rules() This is mainly for debugging purposes and to enable displaying KcCGST values from RMLVO resolution in `xkbcli compile-keymap --kccgst`.
Pierre Le Marre f3a4eeaa 2025-03-26T16:04:39 symbols: Improve keysym parsing
Pierre Le Marre e5401b07 2025-03-26T16:02:58 symbols: Improve Modmap parsing Parse, dont’t validate: ensure *at parsing* that `modifier_map` definitions use a list of keys and keysyms. This enables to remove the redundant `ExprResolveKeySym` and have keysym parsing exclusively in handled in `parser.y`.
Pierre Le Marre 70d11abd 2025-03-26T07:38:05 messages: Add file encoding and invalid syntax entries Added: - `XKB_ERROR_INVALID_FILE_ENCODING` - `XKB_ERROR_INVALID_RULES_SYNTAX` - `XKB_ERROR_INVALID_COMPOSE_SYNTAX` Changed: - `XKB_ERROR_INVALID_SYNTAX` renamed to `XKB_ERROR_INVALID_XKB_SYNTAX`.
Pierre Le Marre fe0d3742 2025-03-18T14:41:30 registry: Fix typo in variable declaration
Pierre Le Marre e8561909 2025-03-18T14:34:10 xkbcomp: Fix keycodes bounds - Refactor to check conflicts first for the key names and then for the keycodes. This seems more useful for the user and enable further memory optimizations. - Do not allocate until we are sure to add the keycode. The bounds are only updated afterwards, so the call to `FindKeyByName` should be more efficient. - Fixed keycodes bounds not shrunk correctly when an existing keycode is overridden. - Do not prepare keyname strings for logging if we are not going to use them.
Pierre Le Marre 4e90cb9c 2025-03-17T07:02:07 xkbcomp: Improve logging of virtual modifiers When logging about virtual modifier *explicit* mappings, we should always use only real modifiers or hexadecimal numbers to print the mask. Consider: ``` virtual_modifiers M1, M2=0x200, M2=0x400; ``` Before this commit we would get the following warning: ``` WARNING: Virtual modifier M2 defined multiple times; Using M2, ignoring M1 ``` while we would prefer the less confusing: ``` WARNING: Virtual modifier M2 defined multiple times; Using 0x400, ignoring 0x200 ```
Pierre Le Marre 02b32244 2025-03-10T13:19:37 registry: Use safer contextual libxml2 functions Avoid using functions depreacted in 2.13 and 2.14 libxml releases. Follow-up of: 5f1b06b7497dc0e69ecfef8a934bce01f4f7fe8e.
Ran Benita 9953d9f0 2025-03-10T21:58:05 xkbcomp/ast-build: fix possible UB in expr AST node allocations (#659) The expression AST constructors all return `ExprDef *`. `ExprDef` is a union of all expr types. As a memory optimization, instead of allocating `sizeof(ExprDef)`, we only allocate the size of the actual type (e.g. `sizeof(ExprBinary)`) which is sometimes smaller than `sizeof(ExprDef)`. This is probably undefined behavior, and gcc (with optimization turned on) complains about it, for example: src/xkbcomp/ast-build.c:69:23: warning: array subscript ‘ExprDef[0]’ is partly outside array bounds of ‘unsigned char[24]’ [-Warray-bounds=] Since it doesn't save that much memory, drop this optimization. Fix #292. Signed-off-by: Ran Benita <ran@unusedvar.com>
Julian Orth cb3565b1 2025-03-07T17:59:33 keymap: Fix segfault due to invalid group wrapping The modular arithmetic is incorrect for negative values, e.g. for num_groups = 1. It triggers a segfault for the following settings: - layouts count (per key or total) N: `N > 0`, and - layout index n: `n = - k * N` (`k > 0`) % returns the *remainder* of the division, not the modulus (see C11 standard 6.5.5 “Multiplicative operators”: a % b = a - (a/b)*b. While both operators return the same result for positive operands, they do not for e.g. a negative dividend: remainder may be negative (in the open interval ]-num_groups, num_groups[) while the modulus is always positive. So if the remainder is negative, we must add `num_groups` to get the modulus. Fixes: 67b03cea ("state: correctly wrap state->locked_group and ->group") Signed-off-by: Julian Orth <ju.orth@gmail.com> Co-authored-by: Julian Orth <ju.orth@gmail.com> Co-authored-by: Pierre Le Marre <dev@wismill.eu>
Pierre Le Marre e1892266 2025-02-13T16:57:46 clang-tidy: Miscellaneous fixes
Pierre Le Marre 5ef19bcf 2025-02-13T17:58:21 xkbcomp: Fix incorrect memory comparison Spotted by clang-tidy: ``` ../src/keymap-priv.c:146:16: warning: comparing object representation of type 'union xkb_action' which does not have a unique object representation; consider comparing the members of the object manually [bugprone-suspicious-memory-comparison] ```` Indeed, from “EXP42-C. Do not compare padding data”[^1]: > unnamed members of objects of structure and union type do not participate > in initialization. Unnamed members of structure objects have indeterminate > representation even after initialization. Fixed by using a dedicated comparison function for `union xkb_action`. [^1]: https://wiki.sei.cmu.edu/confluence/display/c/EXP42-C.+Do+not+compare+padding+data
Pierre Le Marre 6c9806ae 2025-02-12T07:46:07 xkbcomp: Fix ExprResolveMaskLookup error message
Pierre Le Marre 558447d8 2025-02-11T17:34:27 xkbcomp: Explicit vars initialization The `Resolve*` functions do not always initialize the parameters that they can modify, so it is safer to always initialize them at the call site.
Pierre Le Marre 97698fca 2025-02-11T17:34:23 xkbcomp: Use explicit int sizes for Expr resolution
Pierre Le Marre 2d94da3d 2025-02-11T17:34:15 xkbcomp: Fix the int type of ExprInteger Avoid implicit conversion from `int64_t`.
Pierre Le Marre 350931ad 2025-02-12T14:20:58 xkbcomp: Fix compat group index
Pierre Le Marre f2dd0302 2025-02-12T14:15:26 xkbcomp: Fix LED index int type
Pierre Le Marre 2d111bbe 2025-02-12T13:54:51 xkbcomp: Fix possible overflow in numbers parser
Pierre Le Marre a4038a47 2025-02-12T09:50:36 Miscellaneous int types fixes
Pierre Le Marre e3108182 2025-02-12T09:49:25 Fix int casts related to layout index - XkbWrapGroupIntoRange - State
Pierre Le Marre 14a816e5 2025-02-11T18:41:08 xkbcomp: Fix int cast
Pierre Le Marre 3a0b77f0 2025-02-12T16:41:09 xkbcomp: Fix parser headers
Pierre Le Marre 16e3e3cb 2025-02-12T16:12:42 utils: Fix missing headers
Pierre Le Marre ce9bcbe0 2025-02-07T16:31:37 scripts: Rename keysyms-related files Previous names were too generic. Fixed by using explicit names and add the `.py` file extension.
Ran Benita bb5e464e 2025-02-07T14:30:51 xkbcomp/expr: remove comment on ExprResolveIntegerLookup What it says mostly no longer holds, I think it's more confusing than helpful now. Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita aa3e4c71 2025-02-07T14:10:16 xkbcomp/expr: remove unused ExprResolveKeyCode This function was added in commit 4e22851141d89436c0659e68da57e91bbf971461. But that commit also changed the grammar: -KeyNameDecl : KeyName EQUALS Expr SEMI +KeyNameDecl : KeyName EQUALS KeyCode SEMI i.e. while before you could write <AE01> = 9+1; now this is a syntax error, an integer literal is expected. I'm not sure if it was intended to remove this ability. In any case, this rendered `ExprResolveKeyCode` useless since there's no longer an expression to evaluate, and after some refactoring it went unused. Even if we choose to restore Expr here, I don't see a reason for the specialized function over `ExprResolveInteger` except the type (which we should probably widen from int to int64_t...). So remove it. Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita a4d782c7 2025-02-06T16:00:19 xkbcomp/ast: remove ExprCommon It's now empty and no longer serves a purpose. Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita 9d7eb849 2025-02-06T15:25:03 xkbcomp/ast: combine expr_value_type into stmt_type This field is a funky attempt at type inference, or perhaps some optimization? Anyway, after careful examination I conclude it serves no purpose except specifying the type of a literal (string/integer/float/boolean/keyname) when `STMT_EXPR_VALUE` (i.e. literal). Remove it and replace `STMT_EXPR_VALUE` with specific statement types for each literal type. Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita d9fc01b3 2025-02-06T15:12:53 xkbcomp/ast: combine expr_op_type into stmt_type It's better to have a single AST type enum. Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita 635c48f8 2025-02-06T14:47:15 xkbcomp: remove unused EXPR_TYPE_ACTION Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita a5c2c746 2025-02-06T12:27:25 Fix a few direct modifications to generated files Accidentally modified generated files in a couple of recent changes. Sync the templates. Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita f4e95280 2025-02-02T22:29:05 xkbcomp/scanner: avoid unneeded strdup of IDENT tokens The allocation is immediately discarded, either turned into a keysym or an atom. So use an sval slice into the input string instead strdup'ing. memusage ./release/bench-compile-keymap --iter=1000 --layout us,de --variant ,neo Before: Memory usage summary: heap total: 534063576, heap peak: 581022, stack peak: 18848 total calls total memory failed calls malloc| 11240525 291897104 0 realloc| 1447657 192307328 0 (nomove:37629, dec:0, free:0) calloc| 430573 49859144 0 free| 13993903 534063576 After: Memory usage summary: heap total: 506839909, heap peak: 581022, stack peak: 18960 total calls total memory failed calls malloc| 8016419 264673437 0 realloc| 1447657 192307328 0 (nomove:37278, dec:0, free:0) calloc| 430573 49859144 0 free| 10769797 506839909 Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita 113ac304 2025-01-25T03:18:01 meson: link tests and benches against shared library, not static library This makes the tests, and especially benches, more realistic, since xkbcommon is almost always used as a shared library. Also significantly reduces the build time with LTO enabled (for me, from 90s to 30s). Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita a380ba52 2025-01-25T07:00:43 Move XKB_EXPORT to headers The Windows dllexport annotation wants to be on the declarations, not the definitions. Signed-off-by: Ran Benita <ran@unusedvar.com>
Pierre Le Marre c051d0ae 2025-02-05T14:09:17 Replace include guards by `#pragma once` (again) Follow-up of df2322d70cb0922f67c41db639a5c70733b4ce66.
Ran Benita df2322d7 2025-02-05T14:41:21 Replace include guards by `#pragma once` We currently have a mix of include headers, pragma once and some missing. pragma once is not standard but is widely supported, and we already use it with no issues, so I'd say it's not a problem. Let's convert all headers to pragma once to avoid the annoying include guards. The public headers are *not* converted. Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita d75702ba 2025-01-25T06:14:55 utils: remove ifdefs for some ancient or obscure compilers If someone needs this, they can let us know... Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita 02456c14 2025-02-02T21:51:20 xkbcomp/keymap: avoid some allocations in ApplyInterpsToKey Reuse the darray. memusage ./release/bench-compile-keymap --iter=1000 --layout us,de --variant ,neo Before: Memory usage summary: heap total: 552866360, heap peak: 581022, stack peak: 18848 total calls total memory failed calls realloc| 2035244 211110112 0 (nomove:37629, dec:0, free:0) After: Memory usage summary: heap total: 534063576, heap peak: 581022, stack peak: 18848 total calls total memory failed calls realloc| 1447657 192307328 0 (nomove:37629, dec:0, free:0) Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita 7e84c845 2025-02-01T17:04:33 xkbcomp/scanner: avoid extra copies for keynames, keywords, identifiers The tokens don't have escapes so no need to use the `buf` for them. Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita 43f6036d 2025-02-01T16:34:00 xkbcomp/keywords: don't require C string for keyword lookup Needed for next commit, but good regardless. No noticeable effect on performance. Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita e120807b 2025-01-29T15:35:22 Update license notices to SDPX short identifiers + update LICENSE Fix #628. Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita 1f436703 2025-01-24T23:04:43 xkbcomp: rework KeysymList AST representation This is similar to the previous commit, for keysym lists. Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita 39689867 2025-01-24T22:43:45 xkbcomp: rework ActionList AST representation The AST is heavily based on intrusive lists for representing lists, but actions are an exception, instead using darray. I don't see any reason for this; it ends up allocating more, and we don't especially need a flat array for this. Change it to use the familiar linked-list style. Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita 6e97f57e 2025-01-29T19:21:43 scanner: speed up token position -> location using a cache Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita 26807a90 2025-01-28T20:24:05 scanner: compute token line/column lazily on errors The scanner functions are hot, and the line/column location tracking is quite expensive. We only use it for errors, which don't need to be fast, because we bail if there are too many; and for warnings, which are usually not shown by default. So only keep the token start pos, and compute the line/column lazily from that. This will also allow some further improvements ahead. bench/rulescomp before: compiled 1000 keymaps in 1.669028s after: compiled 1000 keymaps in 1.550411s bench/compose: before: compiled 1000 compose tables in 2.145217s after: compiled 1000 compose tables in 2.016044s Signed-off-by: Ran Benita <ran@unusedvar.com>
Pierre Le Marre 3249223f 2025-01-30T07:58:20 test: Add check for keymap and compose compilation logs
Pierre Le Marre 502e9e5b 2025-01-29T12:19:10 xkbcomp: Add stricter bounds for keycodes and levels Our current implementation uses continuous arrays indexed by keycodes and levels. This is simple and good enough for realistic keymaps. However, they are allowed to have big values that will lead to either memory exhaustion or a waste of memory (sparse arrays). Added the much stricter upper bounds `0xfff` for keycodes[^1] and 2048 for levels[^2], which should still be plenty enough and provides stronger memory security. [^1]: Current max keycode is 0x2ff in Linux. [^2]: Should be big enough to satisfy automatically generated keymaps.
Pierre Le Marre c85c9bdc 2025-01-27T17:15:06 symbols: Allow levels with different keysyms and actions counts Contrary to groups, there is no reason for levels to restrict the same count of keysyms and actions.
Pierre Le Marre 27ac30b2 2025-01-27T17:13:44 symbols: Normalize levels by dropping NoSymbol & NoAction
Pierre Le Marre af5704dc 2025-01-25T11:01:03 state: Fix empty level not breaking latches In essence empty levels are levels with just a `NoSymbol` keysym and a `NoAction()`, which breaks latches. Fixed regression introduced in fdf2c525977e7e8af4135d593110f5bc1454abd8. Added tests also for the case where the keycode is unknown.
Pierre Le Marre 4ac22263 2025-01-16T23:22:40 keysyms: Check clashes between keysyms names and keywords Due to how our parser is implemented, keysyms names that are also valid keywords require special handling. Added a check for these clashes in the keysym generator. The only current clash, `section`, is already handled. Note that it means that e.g. `section`, `Section` and `sEcTiOn` all parse to the same keysym. This side effect is fine here, because *currently* there is no other keysym that clashes with any possible of the case variation of `section`. But in order to be extra cautious, we now test thoses clashes too. Hopefully we will never have a clash again, but while it is unlikely that we modify the keywords, the keysyms are not a frozen set.
Pierre Le Marre fc3c8cfd 2025-01-22T16:56:45 Replace STATIC_INSERT with official C11 static_assert
Pierre Le Marre 3ee08251 2025-01-22T16:50:19 clang-tidy: Fix possible leak
Pierre Le Marre 357ab0cb 2025-01-23T16:42:30 clang-tidy: Fix missing default case in switch statement
Pierre Le Marre 842497d9 2025-01-22T16:46:11 clang-tidy: Fix implicit or incorrect integer casts
Pierre Le Marre 5389a31e 2025-01-22T17:33:03 clang-tidy: Use memcpy instead of the insecure strcpy
Pierre Le Marre 53b3f446 2025-01-22T17:43:53 clang-tidy: Fix headers includes
Pierre Le Marre 0c940827 2025-01-22T16:39:35 clang-tidy: Macro arguments should be enclosed in parentheses
Pierre Le Marre 7c124fd9 2025-01-22T17:20:04 rules: Fix incrementing a variable in a complex condition
Pierre Le Marre 818b1b6b 2025-01-22T17:19:41 symbols: Simplify GetGroupIndex call
Pierre Le Marre a2c9b6b4 2025-01-22T16:57:54 x11: Make assumption explicit
Pierre Le Marre b1e1aae6 2025-01-23T15:20:44 xkbcomp: Fix memory leak when extra content after keymap It triggers with e.g.: ``` xkb_keymap { xkb_keycodes { }; }; }; // erroneous ```
Pierre Le Marre 709027ec 2025-01-23T09:12:15 symbols: Fix inconsistent error handling Currently the following keymap triggers a critical error (invalid `vmods`) only for the second key statement, while it should handle both equally. ``` xkb_keymap { xkb_keycodes { <> = 9; }; xkb_types { }; xkb_compat { }; xkb_symbols { key <> { vmods = [], repeats = false }; key <> { repeats = false, vmods = [] }; }; }; ``` Fixed by parsing the whole symbols body and failing if any error was found.
Pierre Le Marre ec2915fe 2025-01-22T17:18:21 symbols: Fix a possible null pointer deference Introduce a new Expression type, `EXPR_EMPTY_LIST`, to avoid the ambiguity between action and keysym empty lists. Two alternatives were rejected to keep the semantics clear: - Using `EXPR_KEYSYM_LIST`: because we would end up accepting an empty keysym list while processing actions. - Using NULL: convey no info and is hazardous.
Pierre Le Marre 9b7466cf 2025-01-21T16:02:55 atom: Fix missing return value in atom_intern Ensure all control paths return a value.
Pierre Le Marre 425dc634 2025-01-21T15:40:33 Fix some implicit integers casts
Pierre Le Marre 9ef45dc5 2025-01-21T19:55:47 Fix incompatible pointer types with enums The enum casts can possibly lead to unaligned access. The warnings trigger in the Windows CI but not on Linux. One may use `-fshort-enums` with gcc in order to trigger the errors.
Pierre Le Marre b1aecd47 2025-01-21T17:51:56 actions: Fix SwitchScreen screen value range Currently we accept values of -255..255 while parsing the screen value of `SwitchScreen` actions`, but then we silently cast it against `int8_t`, i.e. in range -128..127. We actually do as xkbcomp, but this seems a bug because the target storage is a `char`. Let’s simply raise a parse error if the value does not fit in our type.
Ran Benita 26069b76 2025-01-21T10:48:28 xkbcomp/parser: silence a set but unused warning ``` libxkbcommon.so.0.7.0.p/parser.c:1632:9: warning: variable '_xkbcommon_nerrs' set but not used [-Wunused-but-set-variable] 1632 | int yynerrs = 0; ``` Signed-off-by: Ran Benita <ran@unusedvar.com>
Pierre Le Marre db5e6d30 2025-01-21T11:35:57 registry: Refactor to avoid hazardous casts Inline `rxkb_object_unref` for each type and remove the `destroy` field.
Pierre Le Marre c0762c49 2025-01-20T16:33:50 keymap: Fix buffer unnecessary written twice When dumping the keymap, we first try to write to the buffer and get the min size requirement. Then we reallocate if necessary. However, we should not write it again if we got enough space previously!
Pierre Le Marre 24fe4bac 2025-01-20T16:31:44 Fix undefined behaviours with NULL pointer Issues detected by the sanitizers: - fix indexing NULL pointer - fix zero offset to NULL pointer
Pierre Le Marre 8d0df44a 2025-01-15T19:11:58 text: Ensure mod mask can always be printed entirely
Pierre Le Marre b0d9a790 2025-01-15T12:03:10 vmods: Fix explicit vmods not dumped
Pierre Le Marre c7fdf506 2025-01-16T20:23:28 Use portable integer literal suffixes
Pierre Le Marre e3e44998 2025-01-16T20:23:47 Fix missing or incorrect integer literal suffixes The correct suffix is required in order to have the expected value in a portable way.
Jules Bertholet 3fdd822d 2025-01-16T02:21:29 state: Fix mods not being independently cleared (#584) The modifiers filters should ensure minimal interaction between them, but currently the Latch mod filters are overzealous and mess with the mods from other filters set to be cleared, resulting in some modifiers permanently set. Fixed by clearing mods properly with `OR` rather than direct setting of `state::clear_mods`. While we are at it, `state::set_mods` should be `OR`ed as well. This should not have any impact for now, but this is more future-proof. Fixes #583 Co-authored-by: Jules Bertholet <julesbertholet@quoi.xyz> Co-authored-by: Pierre Le Marre <dev@wismill.eu>
Pierre Le Marre dfa286b2 2025-01-15T13:56:36 compat: Fix Interp & LED merge modes
Pierre Le Marre d43bb955 2024-12-19T18:21:01 symbols: Fix key symbols/actions merge - Fixed field for defined keysyms/actions - Fixed regression introduced by fdf2c525977e7e8af4135d593110f5bc1454abd8
Pierre Le Marre 6c6dbf32 2025-01-07T11:19:30 state: Fix LatchGroup action with latchToLock disabled A `LatchGroup` action with the `latchToLock`` option disabled can apply its latch effect multiple times.
kmx.io     mail     discord kmxgit v0.4.0