| Age | Commit message (Collapse) | Author |
|---|
|
If a key name exceeds 4 characters, the content of scanBuf is not
null-terminated, giving error messages like
syntax error: line 7 of test.xkb
last scanned symbol is: FOOBARm
Errors encountered in test.xkb; not compiled.
(last character of the preceding 'maximum' statement in this case)
X.Org Bug 66345 <http://bugs.freedesktop.org/show_bug.cgi?id=66345>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
This fixes an issue with _exit not declared when building xkbcomp
version 1.2.4 natively on Windows using MinGW32 (version 4.7.2)
from www.mingw.org.
https://bugs.freedesktop.org/show_bug.cgi?id=62365
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
When we opened a new file after encountering a parse error, we weren't
resetting our scan state, and continued to read out of the old buffer
rather than that of the new file.
Fixes a regression introduced in 9887842e ('Use fread() instead of
getc()').
Test case:
xkbcomp -lfhlpR "path/to/xkeyboard-config.git/symbols/*"
The Makefiles in that tree would cause parse errors, the resulting directory
file is incomplete (down from ~12000 to ~230 lines).
Reported-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
...though really, by the time you've added 1023 digits to the number
you want to parse, you've got much bigger problems than an off-by-one
error in your buffer count.
Fixes parfait warnings:
Buffer overflow (CWE 120): In array dereference of (*buf)[nInBuf] with index 'nInBuf'
Array size is 1024 bytes, nInBuf >= 1 and nInBuf <= 1024
at line 625 of xkbscan.c in function 'yyGetNumber'.
Buffer overflow (CWE 120): In array dereference of (*buf)[nInBuf] with index 'nInBuf'
Array size is 1024 bytes, nInBuf <= 1025
at line 632 of xkbscan.c in function 'yyGetNumber'.
[ This bug was found by the Parfait 0.4.2 bug checking tool.
For more information see http://labs.oracle.com/projects/parfait/ ]
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=31647
Signed-off-by: Alistair Leslie-Hughes <leslie_alistair@hotmail.com>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
getc() and ungetc() return and take, respectively, an int rather than a
char to allow for error values as well. Oops.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
Use a constant buffer. Sigh.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
So, it turns out that if you're parsing a fairly large amount of data,
using getc() to get all the input rather than, say, read(), is some kind
of remarkably daft and unperformant idea.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
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.
|
|
|
|
"Conditional jump or move depends on uninitialised value(s)"
|
|
indent -cbi 0 -nprs -nut -npcs -i4 -bli 0 *.c *.h
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
