summaryrefslogtreecommitdiff
path: root/xkbpath.c
AgeCommit message (Collapse)Author
2023-01-03Replace calloc(strlen())+strcpy() pairs with strdup() callsAlan Coopersmith
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2023-01-03Mark more pointers as constAlan Coopersmith
Some suggested by cppcheck, others by manual code inspection Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2023-01-03Mark more functions and variables staticAlan Coopersmith
Stop exporting things that aren't used outside the file that defines them. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2023-01-03XkbAddDirectoryToPath: don't leak existing paths on realloc() failureAlan Coopersmith
Found by cppcheck: xkbpath.c:217:9: error: Common realloc mistake: 'includePath' nulled but not freed upon failure [memleakOnRealloc] includePath = (char **) realloc(includePath, szPath * sizeof(char *)); ^ Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2022-12-11Remove unnecessary checks for NULL pointers before calling free()Alan Coopersmith
Not needed in C89 and later Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2022-12-11Replace uFree() with direct free() callsAlan Coopersmith
All these wrappers did was mess with types and add a test for NULL pointers that isn't needed in C89 and later. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2022-12-11Replace uAlloc() and uTypedAlloc() with direct malloc() callsAlan Coopersmith
All these wrappers did was mess with types. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2022-12-11Use C99 struct initializersAlan Coopersmith
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2022-12-11Variable scope reductionsAlan Coopersmith
Some found by cppcheck, some found by manual code inspection Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2022-12-10Remove register keyword from variable declarationsAlan Coopersmith
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2021-01-21Replace WARN[1-9], ERROR[1-9], etc. with their unnumbered versionPeter Hutterer
Those macros date back to when varargs weren't a thing but they've been #defined to the same value for 17 years now. Patch generated with: for action in WARN INFO ERROR ACTION FATAL WSGO; do sed -i "s/${action}[1-9]/${action}/g" `git ls-files` done Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2021-01-21Remove trailing whitespacesPeter Hutterer
Let's clean this up so I don't have to fight vim and git in removing them. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2020-07-23Fix spelling/wording issuesAlan Coopersmith
Found by using: codespell --builtin clear,rare,usage,informal,code,names Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2019-06-13Error out if we have no default pathPeter Hutterer
The path is set through configure.ac/Makefile.am and always defined anyway. Let's not re-define it here with a different value than our default. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-01-04unifdef -U__UNIXOS2__Alan Coopersmith
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2009-01-21Correct make distcheck and most gcc and sparse warnings.Paulo Cesar Pereira de Andrade
Remaining warnings are due to macros that check address or vectors on the stack and auto generated yacc code. Compiled with default flags and also as: % make CFLAGS=-DENTRY_TRACKING_ON -DDEBUG_ON -DASSERTIONS_ON to ensure the "simplification" of code like: foo.c: <hash>define DEBUG_VAR foo_VAR <hash>include "foo.h" ... foo.h: <hash>ifdef DEBUG_VAR_NOT_LOCAL extern <hash>endif int DEBUG_VAR; ... did not change the author's "intended" logic.
2008-09-05sprintf -> snprintf conversionsAlan Coopersmith
2008-08-18Remove useless longestPath variable.Peter Hutterer
2008-08-18Add some explanatory commentsPeter Hutterer
2008-08-12Indent fixes.Peter Hutterer
indent -cbi 0 -nprs -nut -npcs -i4 -bli 0 *.c *.h
2008-08-12Remove RCS tags.Peter Hutterer
2008-04-17Don't scan paths which make NO SENSE WHATSOEVER TO SCANDaniel Stone
Hey, I wonder if we have XKB files in our directory! I wonder if we haven't bothered with a structure, and let's try to open a file called 'misc' in someone's home directory! What a surprise, it's not a valid XKB file! Let's fail miserably! SURPRISINGLY, THIS IS NOT USEFUL BEHAVIOUR.
2007-09-23Fixed a bunch of const correctness bugs.Tilman Sauerbeck
2004-04-23Merging XORG-CURRENT into trunkXORG-6_7_99_904XORG-6_7_99_903XORG-6_7_99_902XORG-6_7_99_901XORG-6_7_99_2XORG-6_7_99_1XACE-SELINUX-MERGEEgbert Eich
2004-03-14Importing vendor version xf86-4_4_99_1 on Sun Mar 14 00:26:39 PST 2004xf86-4_4_99_1Egbert Eich
2004-03-03Importing vendor version xf86-4_4_0 on Wed Mar 3 04:09:24 PST 2004xf86-4_4_0Egbert Eich
2004-02-26readding XFree86's cvs IDsxf86-4_3_99_903Egbert Eich
2004-02-26Importing vendor version xf86-4_3_99_903 on Wed Feb 26 01:21:00 PST 2004Egbert Eich
2003-11-14XFree86 4.3.0.1xf86-4_3_0_1PRE_xf86-4_3_0_1Kaleb Keithley
2003-11-14R6.6 is the Xorg base-lineXORG-MAINKaleb Keithley