Make it a bit easier to understand how exactly the name string is copied into
the reply payload: just do the little memcpy() right where the target position
is decided any the rest of the payload is filled.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of relying on memcpy() coping with NULL buffer when size == 0,
move the call to the branch where we actually have things to copy.
This also silences yet another analyzer warning.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of relying on memcpy() coping with NULL buffer when size == 0,
move the call to the branch where we actually have things to copy.
This also silences yet another analyzer warning.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of relying on memcpy() coping with NULL buffer when size == 0,
move the call to the branch where we actually have things to copy.
This also silences yet another analyzer warning.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplifying the code flow allocating/checking/copying some buffers in
RRConfigureOutputProperty() and RRConfigureProviderProperty() so it's
easier to understand for both the human reader as well as the analyzer.
Depending on whether we have elements to process, a temporary buffer needs
to be allocated, checked for successful allocation and copy over data. The
way it's currently done is technically correct, but unnecessarily complex to
understand: instead of just branching on whether there are elements and doing
all the buffer-related things only then, the branching is done just somewhere
in the middle, only on checking for allocation failure, and relying on both
calloc() and memcpy() not doing weird things when size is zero.
It's easy to simplify by putting it all behind one if statement and so make
things easier for both human reader as well as the analyzer (so it's not
spilling out false alarms here anymore) and also drops unnecessary calls
in the zero-size case.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
1. We've got some ancient code here that's trying to open stderr (fd 2) itself,
in case it cannot write there for strange reason. POSIX defines the three
standard streams (and associated fd's) to be available on program startup
(when main() is reached). One needs a sledgehammer for breaking a system
so much that this doesn't work anymore - even calling a program directly
from /etc/inittab does provide them.
2. The current implementation is not POSIX conformant - it should use freopen(),
and it leaks FILE structure.
3. stderr is set to buffered mode, quite the opposite of POSIX - it states
stderr shall NOT be buffered. Simple and obvious reason: not risking vital
error information getting lost.
4. Placing The logfile in /usr/adm - an ancient, pre-FHS, directory that rarely
exists on modern systems. That's even hardcoded, instead of derived from
build-time given installation pathes.
Conculusio: obsolete and broken, thus removing it.
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>
calloc() can always fail, so we need to prepared for this,
instead of just blindly segfault'ing.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
If this happens, we really have a bug, so better spit out a warning
instead of just segfault'ing.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Usually shouldn't happen trying to accessing pixmap's glamor private
data w/o having it initialized first. But just in case there's some
subtle bug, adding extra checks, which don't cost us much.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
GetPictureScreenIfSet() is designed that NULL can be returned.
Even though it should not happen in this particular case,
better be prepared for that, instead of just segfault'ing.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It could potentially be called with NULL pointer, but can't handle it,
so when that happens, it's a bug. Adding a BUG_RETURN_VAL() call here,
so it's giving us a hint where to look at.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though the cases might be hypothetical, it's still better having some
tiny extra checks (that might be even optimized-out) and reduce the analyzer
noise a bit.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In the rare case that NULL kbd is passed and also no components provided,
the corresponding error message code crashes on NULL pointer dereference.
| ../xkb/ddxLoad.c: In function ‘XkbDDXLoadKeymapByNames’:
| ../xkb/ddxLoad.c:393:25: warning: dereference of NULL ‘keybd’ [CWE-476] [-Wanalyzer-null-dereference]
| 393 | keybd->name ? keybd->name : "(unnamed keyboard)");
| | ~~~~~^~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though shouldn't be practically hit, better have some asserts,
giving us an idea of the point of cause, instead of segfaulting,
just in case.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Try to gracefully handle OOM situation, at not hard crashing.
| ../Xi/xibarriers.c: In function ‘add_master_func’:
| ../Xi/xibarriers.c:729:19: warning: dereference of NULL ‘pbd’ [CWE-476] [-Wanalyzer-null-dereference]
| 729 | pbd->deviceid = *deviceid;
| | ~~~~~~~~~~~~~~^~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Protect against `inputMasks` could be NULL.
| ../Xi/exevents.c: In function ‘DeviceEventSuppressForWindow’:
| ../Xi/exevents.c:3246:32: warning: dereference of NULL ‘inputMasks’ [CWE-476] [-Wanalyzer-null-dereference]
| 3246 | FreeResource(inputMasks->inputClients->resource, X11_RESTYPE_NONE);
| | ~~~~~~~~~~^~~~~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Enrico Weigelt, metux IT consult