|
ca7aa69c
|
2023-09-26T17:05:05
|
|
Disallow producing NULL character with 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.
|
|
|
5b5b67f2
|
2023-05-01T22:30:41
|
|
Add support for modmap None (#291)
Unlike current xkbcommon, X11’s xkbcomp allows to remove entries in
the modifiers’ map using “modifier_map None { … }”.
“None” is translated to the special value “XkbNoModifier” defined in
“X11/extensions/XKB.h”. Then it relies on the fact that in "CopyModMapDef",
the following code:
1U << entry->modifier
ends up being zero when “entry->modifier” is “XkbNoModifier” (i.e. 0xFF).
Indeed, it relies on the overflow behaviour of the left shift, which in
practice resolves to use only the 5 low bits of the shift amount, i.e.
0x1F here. Then the result of “1U << 0xFF” is cast to “char”, i.e. 0.
This is a good trick but too magical, so in libxkbcommon we will use
an explicit test against our new constant XKB_MOD_NONE.
|
|
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>
|
|
a931740c
|
2014-09-10T13:29:52
|
|
keycodes: fix keymap compilation with no aliases and malloc(0)==NULL
If the keymap doesn't have any key-aliases (which is certainly
possible), the calloc(num_key_aliases, ...) is allowed to return NULL
according to the C standard, but this is not an error.
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>
|
|
|
f5182bbd
|
2014-07-26T22:29:22
|
|
test: add file with a syntax error
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>
|
|
|
e91d2653
|
2013-08-01T23:09:46
|
|
scanner: allow empty key name literals
Some keymaps actually have this, like the quartz.xkb which is tested. We
need to support these.
https://bugs.freedesktop.org/show_bug.cgi?id=67654
Reported-By: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
54f95f49
|
2013-03-18T21:02:35
|
|
test: Add flags argument to test_get_context()
Allowing overriding of environment suppression, at first.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
14842d6d
|
2013-03-01T21:48:02
|
|
keymap: abstract a bit over the keymap format
Make it a bit easier to experiment with other formats.
Add a struct xkb_keymap_format_operations, which currently contains the
keymap compilation and _get_as_string functions. Each format can
implement whatever it wants from these.
The current public entry points become wrappers which do some error
reporting, allocation etc., and calling to the specific format. The
wrappers are all moved to src/keymap.c, so there are no XKB_EXPORT's
under src/xkbcomp/ anymore.
The only format available now is normal text_v1.
This is all not very KISS, and adds some indirection, but it is helpful
and somewhat cleaner.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
22684cd1
|
2012-09-30T10:50:38
|
|
parser: remove XkbCompMapList rule
This rule allows you to put several xkb_keymaps in one file.
This doesn't make any sense: only the default/first can ever be used,
yet the others are fully parsed as well.
Different keymaps should just be put in different files.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
fcd20290
|
2012-09-21T14:44:17
|
|
Don't use xkbcommon-compat names in internal code
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
b2110705
|
2012-09-16T14:45:32
|
|
Organize src/ and test/ headers
- Add context.h and move context-related functions from xkb-priv.h to
it.
- Move xkb_context definition back to context.c.
- Add keysym.h and move keysym upper/lower/keypad from xkb-priv.h to it.
- Rename xkb-priv.h to map.h since it only contains keymap-related
definitions and declarations now.
- Remove unnecessary includes and some and some other small cleanups.
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>
|
|
|
6021a976
|
2012-08-03T03:45:14
|
|
test: Minimise includes
Mostly from functions which used to use file functions directly, but now
use test.h wrappers.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
b0b11c4e
|
2012-08-02T00:29:07
|
|
types: don't use canonical/required types
Xkb required every keymap to have at least the four following canonical
types: ONE_LEVEL, TWO_LEVEL, ALPHABETIC, KEYPAD. This is specified in
e.g. the kbproto spec and XkbKeyTypesForCoreSymbols(3) man page.
If these types are not specified in the keymap, the code specifically
checks for them and adds them to the 4 first places in the types array,
such that they exist in every keymap. These are also the types (along
with some non-required 4-level ones) that are automatically assigned to
keys which do not explicitly declare a type (see FindAutomaticType in
symbols.c, this commit doesn't touch these heuristics, whcih are also not
very nice but necessary).
The xkeyboard-config does not rely on the builtin xkbcomp definitions of
these types and does specify them explicitly, in types/basic and
types/numpad, which are virtually always included.
This commit removes the special behavior:
- The code is ugly and makes keytypes.c harder to read.
- The code practically never gets run - everyone who uses
xkeyboard-config or a keymap based upon it (i.e. everyone) doesn't need
it. So it doesn't get tested.
- It mixes policy with implementation for not very good reasons, it
seems mostly for default compatibility with X11 core.
- And of course we don't need to remain compatible with Xkb ABI neither.
Instead, if we read a keymap with no types specified at all, we simply
assign all keys a default one-level type (like ONE_LEVEL), and issue
plenty of warnings to make it clear (with verbosity >= 3). Note that
this default can actually be changed from within the keymap, by writing
something like
type.modifier = Shift
type.whatever_field = value
in the top level of the xkb_types section. (This functionality is
completely unused as well today, BTW, but makes some sense).
This change means that if someone writes a keymap from scratch and
doesn't add say ALPHABETIC, then something like <AE11> = { [ q Q ]; }; will
ignore the second level. But as stated above this should never happen.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
9617b092
|
2012-08-05T12:03:51
|
|
filecomp: fix path and error message
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
c6279b8b
|
2012-07-23T21:21:03
|
|
expr: don't divide by zero
Calculator parser 101.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
9308a460
|
2012-07-17T10:20:15
|
|
Run source tree through uncrustify
.uncrustify.cfg committed for future reference also, but had to manually
fix up a few things: it really likes justifying struct initialisers.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
3e86ebca
|
2012-07-12T14:15:08
|
|
Add a library of common test functions
Including creating a context (will come in useful soon), opening and
reading files, and compiling keymaps.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
059c1842
|
2012-07-12T12:02:19
|
|
Move test data files to test/data/keymaps
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
b89b8e70
|
2012-05-13T23:31:59
|
|
Change xkb_map_new_from_fd to use FILE*
i.e. xkb_map_new_from_file. The reason is that flex only works with
FILE's, so we must use fdopen on the file descriptor; but to avoid a
memory leak, we must also fclose() it, which, in turn, closes the file
descriptor itself.
Either way is not acceptable, so we can either:
* dup() the fd and use fdopen on that, or
* have the user call fdopen on his own, and accept a FILE* instead of an
fd.
The second one seems better, and is standard C, so why not. We must add
stdio.h to xkbcommon.h though, which is regrettable, but not a big deal.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
7b00485a
|
2012-05-11T15:03:43
|
|
Rename 'ctx' back to 'context' in external API
Still keep things as 'ctx' internally so we don't have to worry about
typing it too often, but rename the user-visible API back as it was
kinda ugly.
This partially reverts e7bb1e5f.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
e7bb1e5f
|
2012-05-09T15:03:11
|
|
Shorten context to ctx
(This breaks the API.)
"context" is really annoying to type all the time (and we're going to
type it a lot more :). "ctx" is clear, concise and common in many other
libraries. Use it!
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Fix for xkb -> keymap change.]
|
|
|
38cb6390
|
2012-05-09T15:15:30
|
|
Change all 'xkb' xkb_keymap names to 'keymap'
To make it a bit more clear what it actually is.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
c3584280
|
2012-05-08T17:51:16
|
|
Add flags to context creation
None defined as yet, but why not.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
b537b552
|
2012-05-08T17:48:29
|
|
Add flags to keymap compilation entrypoints
No use as yet, but might as well ...
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
4b49e0a1
|
2012-03-31T02:44:39
|
|
Overhaul test suite
Rewrite all of the current tests in the following ways:
- Instead of the current mix of C and shell, just use single-process
pure C file per test. All of the .sh files are removed, but everything
that was tested is ported.
- Instead of handling the test logs ourselves, use Automake's
"parallel-test" mechanism. This will create a single log file for each
test with it's stdout+stderr, and a top level "test-suite.log" file
for all the failed tests.
- The "parallel-tests" directive also makes the test run in parallel,
so "make check" runs faster.
- Also use the "color-tests" directive to have the "make check" output
colorized. Who doesn't like to see PASS in green?
- All of the test data files are moved into the test/data subdirectory.
That way we can just put the directory in EXTRA_DIST and forget about
it.
- The test/Makefile.am file is consolidated into the main Makefile.am,
for a completely non-recursive build.
Right now the tests are completely independent and just use simple
assert()'s. More sophistication can be added as needed.
It should also be noted that it's still possible to use shell, python,
etc. if a test wants more flexibility than C can provide, just do as
before.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb_keymap changes.]
|
|
|
ef88c7ef
|
2012-04-03T15:14:16
|
|
Rename xkb_desc to xkb_keymap
struct xkb_desc was just a hangover from the old XkbDescRec, which isn't
a very descriptive name.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
9b14e0c3
|
2012-03-29T17:38:44
|
|
Tests: Release context on failure to build keymap
No practical effect since they exit(1) regardless, but it keeps valgrind
happy.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
034ffce6
|
2012-03-27T17:22:35
|
|
Use xkb_contexts in keymap compilation
Primarily for the include path, but also for the logging in future.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
d3908b63
|
2012-03-24T12:33:28
|
|
Define our own None atom value
Since we define our own xkb_atom_t type, it makes sense not to use the
X11/X.h None value. This way we can also remove a lot of X11 includes.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
0480f427
|
2012-03-23T23:28:24
|
|
Remove useless stuff from utils
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: fixed conflicts from strcasecmp, added includes to make
filecomp build again]
|
|
|
d22b8dbb
|
2012-03-23T22:25:47
|
|
Move utils.{c,h} to be used by the entire project
This is a first step for making consistent use of utils.h also outside
of xkbcomp/ .
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
d039622a
|
2012-03-22T17:39:12
|
|
Rename keymap allocation API
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
3077e97e
|
2012-02-15T16:37:31
|
|
tests: Free returned XKB map
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
ead9d0cb
|
2012-02-15T11:49:10
|
|
Move include path from X11/extensions/ to xkbcommon/
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
a84c0879
|
2010-10-19T21:57:59
|
|
Use flex for generating the scanner, add support for parsing from strings
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
|
3f0034a9
|
2010-07-02T11:50:01
|
|
Rename public entry points to lowercase and underscore
|
|
|
5669e1a8
|
2010-07-02T11:43:56
|
|
Compile with -fvisibility=hidden when possible
|
|
|
9f602686
|
2010-07-01T14:35:24
|
|
Pull in enough structs and defines from XKBstr.h to only need XKB.h
We want to move away from sharing implementation structs and let libX11
and libxkbcommon use each their own set of structs.
|
|
|
d95b2893
|
2010-06-30T17:13:21
|
|
Make XkbcInitAtoms() call optional
|
|
|
2c4a045a
|
2010-06-21T14:22:26
|
|
Allow external atom databases
Allow people to plug in an external atom database (e.g. the X server's),
so we don't have to migrate our own atoms over later. We are a bit
over-keen on atoms at the moment, so it does pollute the atom database a
bit though.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
c728d91b
|
2009-04-10T12:33:31
|
|
Program and files for testing CompileKeymapFromFile
A few simple test cases for verifying the operation of parsing a keymap
file and compiling a keyboard description from it.
|