Commit Graph

3 Commits (a17701327e4bc6daa54114041a9707e00e15d82c)

Author SHA1 Message Date
Peter Hutterer b06aedb8ba scanner: allow for a zero terminated string as keymap
As the documentation for xkb_keymap_new_from_buffer() states, the "input string
does not have to be zero-terminated". The actual implementation however failed
with "unrecognized token/syntax error" when it encountered a null byte.

Fix this by allowing a null byte at the last position of the buffer. Anything
else is likely a client error anyway.

Fixes #307
2023-05-05 09:57:23 +10:00
Ran Benita 40aab05e77 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>
2019-12-27 13:09:11 +02:00
David Herrmann 36f55c494e keymap: add xkb_keymap_new_from_buffer()
The current API doesn't allow the caller to create keymaps from mmap()'ed
files. The problem is, xkb_keymap_new_from_string() requires a terminating
0 byte. However, there is no way to guarantee that when using mmap() so a
user currently has to copy the whole file just to get the terminating zero
byte (assuming they cannot use xkb_keymap_new_from_file()).

This adds a new entry xkb_keymap_new_from_buffer() which takes a memory
location and the buffer size in bytes.

Internally, we depend on yy_scan_{string,byte}() helpers. According to
flex documentation these already copy the input string because they are
wrappers around yy_scan_buffer().
yy_scan_buffer() on the other hand has some insane requirements. The
buffer must be writeable and the last two bytes must be ASCII-NUL. But the
buffer may contain other 0 bytes just fine.

Because we don't want these constraints in our public API,
xkb_keymap_new_from_buffer() needs to create a copy of the input memory.
But it then calls yy_scan_buffer() directly. Hence, we have the same
number of buffer-copies as with *_from_string() but without the
terminating 0 requirement.
The explicit yy_scan_buffer() call is preferred over yy_scan_byte() so the
buffer-copy operation is not hidden somewhere in flex.

Maybe some day we no longer depend on flex and can have a zero-copy API. A
user could mmap() a file and it would get parsed right from this buffer.
But until then, we shouldn't expose this limitation in the API but instead
provide an API that some day can work with zero-copy.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

[ran: rebased on top of my branch]
Conflicts:
	Makefile.am
	src/xkbcomp/xkbcomp.c
2013-04-01 18:04:06 +01:00