src/registry.c


Log

Author Commit Date CI Message
Peter Hutterer 8b7c1850 2021-03-19T09:49:24 registry: remove a few asprintf/free() calls with snprintf Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Peter Hutterer a50890b1 2021-03-19T09:46:15 registry: simplify strdup() error handling strdup() is the least likely call to fail here, let's move it to the bottom so we don't need to worry about the allocated string. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Ronan Pigott b4e81ca1 2022-12-16T01:26:25 context: add XKB_CONTEXT_NO_SECURE_GETENV flag (#312) This flag is useful for clients that may have relatively benign capabilities set, like CAP_SYS_NICE, that also want to use the xkb configuration from the environment and user configs in XDG_CONFIG_HOME. Fixes: https://github.com/xkbcommon/libxkbcommon/issues/308 Fixes: https://github.com/xkbcommon/libxkbcommon/issues/129 Signed-off-by: Ran Benita <ran@unusedvar.com>
M Hickford efa99624 2022-01-24T02:16:08 Variants should inherit iso639, iso3166 and brief from parent layout if omitted (#266)
Peter Hutterer 9b05825e 2022-01-20T13:08:36 registry: skip over invalid ISO639 or ISO3166 entries If the XML file is somehow off, don't load entries that are against the spec.
Peter Hutterer 0e3f72af 2022-01-17T13:51:48 registry: don't call xmlCleanupParser() From the documentation: > It does not clean up parser state, it cleans up memory allocated by the library > itself. It is a cleanup function for the XML library. It tries to reclaim all > related global memory allocated for the library processing. [...] > One should call xmlCleanupParser() only when the process has finished using the library. http://xmlsoft.org/html/libxml-parser.html#xmlCleanupParser Since we're a library ourselves we cannot know if something else in the same proces uses the parser, so we must not call this. Reported-by: M Hickford
Peter Hutterer 01aa2222 2021-03-18T11:22:38 registry: plug a potential memleak for invalid rules files If the name is missing in a configItem, we'd fail and leak the memory for description, brief and vendor. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Peter Hutterer 3039d62a 2020-09-07T19:38:47 registry: mark the rxkb_log function as attribute printf Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Peter Hutterer d7b39f6f 2020-07-10T08:50:02 Add /etc/xkb as extra lookup path for system data files This completes the usual triplet of configuration locations available for most processes: - vendor-provided data files in /usr/share/X11/xkb - system-specific data files in /etc/xkb - user-specific data files in $XDG_CONFIG_HOME/xkb The default lookup order user, system, vendor, just like everything else that uses these conventions. For include directives in rules files, the '%E' resolves to that path. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Peter Hutterer 41a7c975 2020-07-10T14:57:57 Add asprintf_safe helper function We only ever care about whether we error out or not, so let's wrap this into something more sane. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Peter Hutterer afb26e7d 2020-05-12T14:09:50 Add libxkbregistry to query available RMLVO This library is the replacement for clients parsing evdev.xml directly. Instead, they should use the API here so that in the future we may even be able to swap evdev.xml for a more suitable data format. The library parses through evdev.xml (using libxml2) and - if requested - through evdev.extras.xml as well. The merge approach is optimised for the default case where we have a system-installed rules XML and another file in $XDG_CONFIG_DIR that adds a few entries. We load the system file first, then append any custom ones to that. It's not possible to overwrite the MLVO list provided by the system files - if you want to do that, get the change upstream. XML validation is handled through the DTD itself which means we only need to check for a nonempty name, everything else the DTD validation should complain about. The logging system is effectively identical to xkbcommon. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>