|
a83d745b
|
2023-09-21T20:06:27
|
|
Messages: add new messages to registry
This commit is another step to identify and document the maximum number
of logging messages. Bulk changes:
- Rename `conflicting-key-type` to `conflicting-key-type-merging-groups`.
Giving more context in the name allow us to introduce
`conflicting-key-type-definitions` later.
- Add conflicting-key-type-definitions
- Add conflicting-key-type-map-entry
- Add undeclared-modifiers-in-key-type
Also improve the log messages.
- Add conflicting-key-type-preserve-entries
- Use XKB_ERROR_UNSUPPORTED_MODIFIER_MASK
- Add illegal-key-type-preserve-result
- Add conflicting-key-type-level-names
- Add duplicate-entry
- Add unsupported-symbols-field
- Add missing-symbols-group-name-index
- Use XKB_ERROR_WRONG_FIELD_TYPE
- Add conflicting-key-name
- Use XKB_WARNING_UNDEFINED_KEYCODE
- Add illegal-keycode-alias
- Add unsupported-geometry-section
- Add missing-default-section
- Add XKB_LOG_MESSAGE_NO_ID
- Rename log_vrb_with_code to log_vrb
- Use ERROR_WRONG_FIELD_TYPE & ERROR_INVALID_SYNTAX
- Add unknown-identifier
- Add invalid-expression-type
- Add invalid-operation + fixes
- Add unknown-operator
- Rename ERROR_UNKNOWN_IDENTIFIER to ERROR_INVALID_IDENTIFIER
- Add undeclared-virtual-modifier
- Add expected-array-entry
- Add invalid-include-statement
- Add included-file-not-found
- Add allocation-error
- Add invalid-included-file
- Process symbols.c
- Add invalid-value
- Add invalid-real-modifier
- Add unknown-field
- Add wrong-scope
- Add invalid-modmap-entry
- Add wrong-statement-type
- Add conflicting-key-symbols-entry
- Add invalid-set-default-statement
|
|
c0065c95
|
2023-09-21T20:06:27
|
|
Messages: merge macros with and without message code
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`.
|
|
95e29079
|
2021-03-18T12:22:34
|
|
xkbcomp: plug a potential memory leak
libxkbcommon-1.0.3/src/xkbcomp/ast-build.c:526: leaked_storage: Variable "file"
going out of scope leaks the storage it points to.
Where we exit the loop early, we don't release the various allocated memory.
Make this patch more obvious my moving the declaration for those into the loop
as well, this way we know that they aren't used outside the loop anywhere.
Found by coverity
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
40aab05e
|
2019-12-27T13:03:20
|
|
build: include config.h manually
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>
|
|
7c42945e
|
2019-11-13T22:41:38
|
|
parser: fix quadratic pointer chasing
In the AST, lists (e.g. the list of statements in a file) are kept in
singly-linked lists -- each AST node has a `next` pointer available for
this purpose.
Previously, a node was added to the list by starting from the head,
chasing to the last, and appending. So creating a list of length N would
take ~N^2/2 pointer dereferences.
Now, we always (temporarily) keep the last as well, so appending is O(1)
instead of O(N).
Given a keymap
xkb_keymap {
xkb_keycodes {
minimum = 8;
minimum = 8;
minimum = 8;
minimum = 8;
minimum = 8;
[... repeated N times ...]
};
xkb_types {};
xkb_compat {};
xkb_symbols {};
};
The compilation times are
N | Before | After
--------|----------|-------
10,000 | 0.407s | 0.006s
20,000 | 1.851s | 0.015s
30,000 | 5.737s | 0.021s
40,000 | 12.759s | 0.023s
50,000 | 21.489s | 0.035s
60,000 | 40.473s | 0.041s
70,000 | 53.336s | 0.039s
80,000 | 72.485s | 0.044s
90,000 | 94.703s | 0.048s
100,000 | 118.390s | 0.057s
Another option is to ditch the linked lists and use arrays instead. I
got it to work, but its more involved and allocation heavy so turns out
to be worse without further optimizations.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
400cc849
|
2019-11-12T20:04:13
|
|
ast: use a separate expr struct for action list
Currently it's under UnaryExpr, which just doesn't make sense.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
8c62d48c
|
2019-11-12T19:16:08
|
|
ast-build: get rid of unhelpful macro
Straightforward code is better here.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
31f1f355
|
2018-09-30T16:04:29
|
|
Fix off-by-one error in index check in xkb_file_type_to_string
Found by Oracle's Parfait 2.2 static analyzer:
Error: Buffer overrun
Read outside array bounds [read-outside-array-bounds] (CWE 125):
In array dereference of xkb_file_type_strings[type] with index type
Array size is 56 bytes, index <= 56
at line 734 of src/xkbcomp/ast-build.c in function 'xkb_file_type_to_string'.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
c1e5ac16
|
2018-07-30T14:11:46
|
|
xkbcomp: fix pointer value for FreeStmt
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
e3cacae7
|
2018-03-10T23:32:12
|
|
xkbcomp: fix crashes in the parser when geometry tokens appear
In the XKB format, floats and various keywords can only be used in the
xkb_geometry section. xkbcommon removed support xkb_geometry, but still
parses it for backward compatibility. As part of ignoring it, the float
AST node and various keywords were removed, and instead NULL was
returned by their parsing actions. However, the rest of the code does
not handle NULLs, and so when they appear crashes usually ensue.
To fix this, restore the float AST node and the ignored keywords. None
of the evaluating code expects them, so nice error are displayed.
Caught with the afl fuzzer.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
2963e29f
|
2017-12-12T14:43:24
|
|
xkbcomp/ast-build: fix memory leak when appending multi-keysyms
`syms` was not freed.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
5e3615b2
|
2014-10-18T20:04:57
|
|
ast-build: remove log message about allocation failure
We don't do so anywhere else, so until we have something comprehensive,
let's not so here.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
4a660d7f
|
2014-10-18T19:47:19
|
|
xkbcomp: remove file->topName
It is useless.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
7a87c202
|
2014-09-10T13:10:33
|
|
ast-build: fix leak in error path
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
40f109af
|
2014-07-27T14:24:20
|
|
ast-build: make sure InterpDef is freeable
With the following two rules:
InterpretDecl : INTERPRET InterpretMatch OBRACE
VarDeclList
CBRACE SEMI
{ $2->def = $4; $$ = $2; }
;
InterpretMatch : KeySym PLUS Expr
{ $$ = InterpCreate($1, $3); }
| KeySym
{ $$ = InterpCreate($1, NULL); }
;
And the fact that InterpCreate doesn't initialize ->def, if the
VarDeclList fails, the %destructor tries to recursively free the
uninitialized ->def VarDef. So always initialize it.
That was the only problematic code in the parser for %destructor (I'm
pretty sure).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
61fed8da
|
2014-07-26T00:19:34
|
|
Replace darray_mem with a new darray_steal
That's a more declarative interface.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
fbd92860
|
2014-07-26T00:13:54
|
|
ast-build: use cast instead of ->common
Missed in 1b2bb204e0baa2246a6232aea762c1edb00cd44a.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
86cfef63
|
2014-05-11T09:47:56
|
|
ast-build: don't leak on OOM in BoolVarCreate
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
1b2bb204
|
2014-02-13T23:57:22
|
|
ast: cast to ParseCommon explictly instead of using ->common
Some tools were getting mighty confused with what we were doing.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
16aab829
|
2014-02-09T23:21:19
|
|
ast: remove unneeded 'ctx' param to XkbFileCreate
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
50b73ec0
|
2014-02-08T15:10:09
|
|
Use unsigned int for saving darray_size return value
See: b9b3593cbdeb7f5b02d50cecaba6a0b47d4979ad
So these should be unsigned int's now.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
6ea15719
|
2014-02-08T01:26:35
|
|
ast: use more suitable types in a few ast nodes
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>
|
|
4884a8e6
|
2013-08-02T10:19:01
|
|
keymap: move XkbEscapeMapName() to keymap.c.
So we can use it outside src/xkbcomp; it is not really specific to it.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
b63fa3b1
|
2013-12-01T13:32:51
|
|
expr: make Expr creation naming and file location consistent
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
07334f4d
|
2013-12-01T13:29:30
|
|
expr: add wrapper macro for ExprCreate
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
972395b8
|
2013-12-01T12:08:47
|
|
expr: split expression types and allocate them separately
Currently, we have one ExprDef type, which contains a tagged union with
the value of all expression types. Turns out, this union is quite
wasteful memory-wise. Instead, create separate types for all expressions
(e.g ExprBinary, ExprInteger) which embed the common fields
(ExprCommon), and malloc them per their size; ExprDef then becomes a
union of all these types, but is just used as a generic pointer.
[Instead of making ExprDef a union, another option is to use
ExprCommon as the generic pointer type and then do up-castings, like we
do with ParseCommon. But this makes the code much uglier.]
The diff is mostly straightforward mechanical adaptations. It could have
been much smaller with the help of C11 anonymous structs (which were
previously a gnu extension). This will have saved all of the 'op' ->
'expr->op', etc changes. But if we can be a bit more portable for a
little effort, we should.
Before (./test/rulescomp, x86 32 bit, -O2):
==12974== total heap usage: 145,217 allocs, 145,217 frees, 10,476,238 bytes allocated
After:
==11145== total heap usage: 145,217 allocs, 145,217 frees, 8,270,358 bytes allocated
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
068016e4
|
2013-12-01T10:45:52
|
|
parser, symbols: drop unnecessary casts
It's casted into ExprDef and then uncasted for no reason.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
4a7bfb68
|
2013-12-01T10:31:27
|
|
expr: use ExprCreate in more places
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
c24b6420
|
2013-11-30T23:24:18
|
|
expr: add constructor for boolean expressions
Also add a 'bool set' to the ExprDef union, instead of using 'ival' as a
bool.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
c5d85938
|
2013-11-30T23:12:45
|
|
expr: add constructors for more expression types
This makes the parser a bit more declarative. But really it might make
error handling easier.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
dbd8b1ef
|
2013-11-30T22:25:39
|
|
expr: add 'ident' value to ExprDef union
This distinguishes between an identifier expression and a string
expression in the union.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
9dc5b8cb
|
2013-11-27T13:49:13
|
|
Resolve keysyms early in parser
Instead of having the parser passing strings to the AST, and
symbols/compat etc. resolving them themselves. This simplifies the code
a bit, and makes it possible to print where exactly in the file the bad
keysym originates from.
The previous lazy approach had an advantage of not needlessly resolving
keysyms from unrelated maps. However, I think reporting these errors in
*any* map is better, and the parser is also a bit smarter then old
xkbcomp and doesn't parse many useless maps. So there's no discernible
speed/memory difference with this change.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
4b560287
|
2013-07-18T14:50:21
|
|
xkbcomp: escape the section names before storing them in the keymap
This ensures the names are escaped before having any interaction with
the user.
This was caught by noticing dump(compile(dump())) != dump. Since that's
a nice test we add it to stringcomp.
https://bugs.freedesktop.org/show_bug.cgi?id=67032
Reported-By: Auke Booij
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
56ba9866
|
2013-03-04T14:16:36
|
|
Remove file_id entirely
It is not used anymore.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
35657c66
|
2013-02-25T16:38:56
|
|
ast-build: remove malloc_or_die
This should be fixed properly.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
d1f7100b
|
2013-02-25T01:12:38
|
|
ast: add error handling to XkbFileFromComponents
And try to not repeat ourselves.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
fc56b513
|
2013-02-08T00:02:49
|
|
ast: constify argument
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
8cee7490
|
2013-02-17T22:18:57
|
|
Change 'indicator' to 'led' everywhere possible
The code currently uses the two names interchangeably.
Settle on 'led', because it is shorter, more recognizable, and what we
use in our API (though of course the parser still uses 'indicator').
In camel case we make it 'Led'.
We change 'xkb_indicator_map' to just 'xkb_led' and the variables of
this type are 'led'. This mimics 'xkb_key' and 'key'.
IndicatorNameInfo and LEDInfo are changed to 'LedNameInfo' and
'LedInfo', and the variables are 'ledi' (like 'keyi' etc.). This is
instead of 'ii' and 'im'.
This might make a few places a bit confusing, but less than before I
think. It's also shorter.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
89523789
|
2012-10-11T21:50:21
|
|
ast: simplify AppendStmt
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
41a7fed3
|
2012-09-27T19:21:26
|
|
Fix type of keycode in parser and ast
For some reason keycodes were listed under mapFlags in the yylval union.
Fix it and some sanity checks.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
3b389b15
|
2012-09-27T18:49:13
|
|
Don't limit key names to 4 characters
Currently you can't give a key in xkb_keycodes a name of more than
XKB_KEY_NAME_LENGTH (= 4) chars. This is a pretty annoying and arbitrary
limitation; it leads to names such as <RTSH>, <COMP>, <PRSC>, <KPAD>
etc. which may be hard to decipher, and makes it impossible to give
more standard names (e.g. from linux/input.h) to keycodes.
The purpose of this, as far as I can tell, was to save memory and to
allow encoding a key name directly to a 32 bit value (unsigned long it
was).
We remove this limitation by just storing the names as atoms; this lifts
the limit, allows for easy comparison like the unsigned long thing, and
doesn't use more memory than previous solution. It also relieves us from
doing all of the annoying conversions to/from long.
This has a large diffstat only because KeyNameText, which is used a lot,
now needs to take the context in order to resolve the atom.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
c1741732
|
2012-09-21T11:14:39
|
|
Don't choke on RMLVO layout string with holes
This old rules parser gives the same kccgst here, so in the interest of
staying compatible we shouldn't fix it there. Similarly we shouldn't
touch ParseIncludeMap, so this is the best place to handle this.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
b4b40d73
|
2012-09-12T16:54:07
|
|
Copyright updates
With Dan Nicholson's permission (via email), update his copyright and
license statements to the standard X.Org boilerplate MIT license, as
both myself and Ran have been using.
Clean up my copyright declarations (in some cases to correct ownership),
and add copyright/license statements from myself and/or Ran where
appropriate.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
b6e04571
|
2012-09-10T20:16:05
|
|
kbproto unentanglement: XkbLC_*
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
f5dffd2b
|
2012-08-21T11:21:19
|
|
kbproto untanglement: XkbKeyNameLength
Define it ourselves as XKB_KEY_NAME_LENGTH and use that, instead of the
one from XKB.h.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
591df115
|
2012-08-27T19:20:41
|
|
Move enum xkb_file_type to xkbcomp/ast.h
This is a more suitable place for this enum, since it's internal to
xkbcomp.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
efc2d741
|
2012-08-27T18:58:36
|
|
xkbcomp: clean up compile_keymap function
We make the xkb_file_type enum sequential instead of masks, and then
we don't have to repeat the file types several times in the function.
Makes the code cleaner.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
d3ddcf70
|
2012-08-15T21:45:02
|
|
expr: move op_type/value_type_to_string functions to ast
Generally the enum-to-string function should appear where the enum is
defined.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
cdc228ea
|
2012-08-13T11:00:43
|
|
Organize xkbcomp/ header files
Various non-functional changes:
- Re-add keycodes.h and move some stuff there.
- Add parser-priv.h for internal bison/flex stuff.
- Don't include headers from other headers, such that file dependencies
are immediate in each file.
- Rename xkbcomp.h -> ast.h, parseutils.{c,h} -> ast-build.{c,h}
- Rename path.{c,h} -> include.{c,h}
- Rename keytypes.c -> types.c
- Make the naming of XkbFile-related functions more consistent.
- Move xkb_map_{new,ref,unref} to map.c.
- Remove most extern keyword from function declarations, it's just
noise (XKB_EXPORT is what's important here).
- Append XKBCOMP_ to include guards.
- Shuffle some code around to make all of this work.
Splitting this would be a headache..
Signed-off-by: Ran Benita <ran234@gmail.com>
|