It's safer not relying on all ScreenProc's actually filled.
../dix/events.c: In function ‘CheckPhysLimits’:
../dix/events.c:780:14: warning: dereference of NULL ‘pScreen’ [CWE-476] [-Wanalyzer-null-dereference]
780 | (*pScreen->SetCursorPosition)
| ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The pointer to the window properties is currently inside the WindowOptional
structure, which may or may not exist at any given time. Thus, before accessing
those fields, at least need to check whether it exists, potentially need to
create it first.
Since a pointer is small (in relation to WindowRec) and windows having properties
is a pretty common, we can make our life much simpler here by moving the pointer
directly into WindowRec, so we don't need extra WindowOptionalRec allocation.
This also fixes an analyzer warning on potential NULL dereference issue:
| ../dix/property.c: In function ‘dixChangeWindowProperty’:
|../dix/property.c:343:37: warning: dereference of NULL ‘*pWin.optional’ [CWE-476] [-Wanalyzer-null-dereference]
| 343 | pProp->next = pWin->optional->userProps;
| | ~~~~~~~~~~~~~~^~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Be more cautious on possible NULL pointers or not yet registered
devPrivates. Better a gracefully fail instead of hard segfault.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though it *should* never be actually hit, it's still safer
to check for NULL instead of letting us crash with segfault.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though it's unlikely ever getting it, still safer to have some
extra checks / asserts than unexpected segfault.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Safer (and easier to understand) if we look at the result pointer
instead of the counter for testing whether device wasn't found.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Better try to handle memory allocation gracefully than just hard
crashing by segfault.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though chances are really low it's ever getting hit, it's still safer
to have some sanity checks (which don't cost us much) than risking segfault.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There's (remote) chance that the (internal) module name could become
NULL (eg. allocation failure). Even though chances to hit it are very
low, it's still better to have a check here (that doesn't cost us much),
just in case. Assert fail is still better than segfault, since we're
at least getting some hint what might have happened.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Adding paranoid extra checks against allocation failure and NULL pointers.
Even though might not be actually hit in practise, it's still better to
be cautious, just in case. And reducing analyzer noise this way.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The analyzer warnings (possible NULL dereference) are probably just
false alarms. But for safety adding assert()'s, which don't cost us
anything in non-debug builds.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's only rarely used and can be easily achieved by generic means,
eg. via ulimit or supervisor settings.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
A slight change in include order can cause Xlib to be included and defining
"GC" type, which is conflicting with Xserver's own type by same name.
As long as MR !1393 hasn't merged yet, we need to do an ugly workaround
using some preprocessor black magic.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It doesn't serve any practical purpose anymore and also isn't included
by any external driver, thus also no need to keep it in SDK.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Protecting against NULL pointers and allocation failures.
Printing out a bug warning in those cases.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's now only a wrapper calling xf86PostKeyEvent(), and no external driver
using it anymore, so we can drop it entirely.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Enrico Weigelt, metux IT consult