- 19 Oct, 2016 40 commits
-
-
Alan Coopersmith authored
instead of converting to int and back Fixes clang warnings of the form: HVC.c:190:43: warning: implicit conversion changes signedness: 'int' to 'unsigned long' [-Wsign-conversion] if (strncmp(spec, _XcmsTekHVC_prefix, n) != 0) { ~~~~~~~ Signed-off-by:Alan Coopersmith <alan.coopersmith@oracle.com> Backported-to-NX-by:
Ulrich Sibiller <uli42@gmx.de>
-
Alan Coopersmith authored
Clears many gcc warnings of the form: uvY.c: In function ‘XcmsCIEuvYToCIEXYZ’: uvY.c:263:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (i = 0; i < nColors; i++, pColor++) { ^ Signed-off-by: -
Alan Coopersmith authored
Fixes gcc warnings of the form: IdOfPr.c: In function ‘XcmsFormatOfPrefix’: IdOfPr.c:69:32: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if ((len = strlen(prefix)) >= sizeof(string_buf)) { ^ IdOfPr.c:83:11: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (len >= sizeof(string_buf)) Xfree(string_lowered); ^ IdOfPr.c:97:11: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (len >= sizeof(string_buf)) Xfree(string_lowered); ^ IdOfPr.c:104:13: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (len >= sizeof(string_buf)) Xfree(string_lowered); ^ Signed-off-by: -
Dominik Muth authored
The basic rule "put parantheses around macro parameters" should be observed where possible. Otherwise code like ConnectionNumber(foo = bar); fails to compile. (It obviously passes if ConnectionNumber is a C function.) There are several other macros amended for the same reason. This bug appeared while building http://ioccc.org/1993/cmills.c, so historically it was not present. Signed-off-by:Dominik Muth <muth@nxdomain.no-ip.biz> Reviewed-by:
-
Olivier Fourdan authored
XkbGetKeyboardByName relies on flags to read the data from the server. If the X server sends us the wrong flags or if a subreply is smaller than it should be, XkbGetKeyboardByName will not read all the available data and leave data in the buffer, which will cause the next _XReply() to fail with: [xcb] Extra reply data still left in queue [xcb] This is most likely caused by a broken X extension library [xcb] Aborting, sorry about that. xcb_io.c:576: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed. Aborted Check if there is some extra data left at the end of XkbGetKeyboardByName() and discard that data if any is found. Many thanks to Peter Hutterer <peter.hutterer@who-t.net> for finding the root cause of the issue and Adam Jackson <ajax@redhat.com> for helping with the analysis! Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Daniel Stone <daniels@collabora.com> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by:
-
Alan Coopersmith authored
Signed-off-by:
Adam Jackson <ajax@redhat.com> Backported-to-NX-by:
-
Alan Coopersmith authored
Signed-off-by:
-
Alan Coopersmith authored
Signed-off-by:
-
Alan Coopersmith authored
Signed-off-by:
-
Alan Coopersmith authored
Don't need to test for a case that we already returned for, don't need to store a count that will only ever be 1 if we didn't return, don't need to increment pointers to allow storing more than one item when we can only ever possibly do one. Signed-off-by:
-
Alan Coopersmith authored
Code seems to have been originally written to handle appending multiple strings, but only ever operates on a single string. Signed-off-by:
-
Alan Coopersmith authored
Signed-off-by:
-
Alan Coopersmith authored
Signed-off-by:
-
Alan Coopersmith authored
Rework code to store allocations directly into XIM struct instead of temporary local variables, so we can use _XCloseIM to unwind instead of duplicating it, and consistently jump to error handler on failure, instead of sometimes leaking and sometimes freeing. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93183Signed-off-by:
-
Alan Coopersmith authored
Free the correct bits of memory if we run out and need to unwind Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93184Signed-off-by:
-
Alan Coopersmith authored
The only use of XCONN_CHECK_FREQ was removed in commit 15e5eaf62897b3179 when we dropped the old Xlib connection handling in favor of xcb's. Signed-off-by:
Mark Kettenis <kettenis@openbsd.org> Backported-to-NX-by:
-
Alan Coopersmith authored
Signed-off-by:
Thomas Klausner <wiz@NetBSD.org> Backported-to-NX-by:
-
Thomas Klausner authored
Signed-off-by:
-
Ross Burton authored
ICWrap.c dereferences the xim parameter passed in from client code without a NULL check. I have seen mplayer trigger this resulting in a segfault. In this case mplayer had called XOpenIM and NULL was returned which was later passed into XCreateIC. Patch originally by Drew Moseley <drew_moseley@mentor.com>. Signed-off-by:
Ross Burton <ross.burton@intel.com> Reviewed-by:
-
Alan Coopersmith authored
Signed-off-by:
-
Bhavi Dhingra authored
Incorrect parameter usage with sizeof. Earlier passed argument FontData will be 4 bytes always as its a pointer hence the change is needed and FontDataRec should be used for memset. Reviewed-by:
-
Peter Hutterer authored
False positive, if rlen/nbytes are unset we quit early before using it. Still, initialize it so we don't have to deal with these warnings again. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
Peter Hutterer authored
If we hit the depth limit, filename leaks. Move the depth check up before we allocate filename. Introduced in 226622349a4b1e16064649d4444a34fb4be4f464. Signed-off-by:
-
Ran Benita authored
The Compose format has a feature which allows specifying certain modifiers must (or must not) be present with a given keysym in the sequence. The grammar in imLcPrs.c and the Compose man page both do not match what the code actually does (see the handling of the variables `modifier_mask` and `modifier` in parseline() in imLcPrs.c, which are eventually matched as `ev->state & modifier_mask == modifier`). Also explicitly list the accepted modifier names, since they are not standard (e.g. "Ctrl" instead of "Control"). Signed-off-by:
Ran Benita <ran234@gmail.com> Signed-off-by:
James Cloos <cloos@jhcloos.com> Backported-to-NX-by:
-
Alan Coopersmith authored
Forces compiler to zero-fill unset fields in the struct (fixing bug 81236) and allows optimizer to order field initialization to best fit cache layout or other considerations. Before & after output of gcc -S on AMD64 shows insertion of "rep stosq" instructions to rapidly zero-fill structs. Signed-off-by:
Matthieu Herrb <matthieu@herrb.eu> Backported-to-NX-by:
-
Alan Coopersmith authored
Nothing in the XKB spec states that the memory pointed to by ctrls has to be initialized to any given value when passed to the function, only that it is set by the function to the values returned by the X server: http://www.x.org/releases/X11R7.7/doc/libX11/XKB/xkblib.html#The_Miscellaneous_Per_client_Controls The check for the incoming value seems to be copied from XkbSetPerClientControls without explanation. Instead change it to checking if ctrls is non-NULL, since there's no point asking the X server to return a value the caller won't even see. Found while investigating report from cppcheck-1.65: [nx-X11/lib/X11/XKB.c:699] -> [nx-X11/lib/X11/XKB.c:719]: (warning) Possible null pointer dereference: ctrls - otherwise it is redundant to check it against null. Signed-off-by:
-
Alan Coopersmith authored
Check is intended to ensure we allocate at least XkbNumRequiredTypes in map, but was accidentally marked with a ! causing the wrong check. Reported-by:
Harms <wharms@bfs,de> Reviewed-by:
-
walter harms authored
* Do not use variables before checked for NULL. * remove some superfluid spaces (Mark Kettenis) Signed-off-by:
-
walter harms authored
remove more redundant NULL checks note that _XkbFree() is really Xfree() Signed-off-by:
Rémi Cardona <remi@gentoo.org> Signed-off-by:
-
walter harms authored
This patch removes the last remaining NULL checks for Xfree() Signed-off-by:
-
walter harms authored
Signed-off-by:
-
walter harms authored
This patch removes some redundant null checks before free. It should not change the code otherwise. Be aware that this is only the first series. Signed-off-by:
-
walter harms authored
* Do not use variables before checked for NULL. Signed-off-by:
-
walter harms authored
* Do not use variables before checked for NULL. Signed-off-by:
-
walter harms authored
* Do not use variables before checked for NULL. Signed-off-by:
-
Owen W. Taylor authored
When XCB owns the X socket, dpy->request is not updated, so NextRequest() and XNextRequest() return the wrong value. There's nothing we can do to fix NextRequest() while retaining ABI compat, but change XNextRequest() to grab the socket back from XCB, updating dpy->request. Signed-off-by:
Owen W. Taylor <otaylor@fishsoup.net> Reviewed-by:
Uli Schlachter <psychon@znc.in> Signed-off-by:
-
Ran Benita authored
The build doesn't provide any way to define this option. It also refers to files (imComp.h) and functions (e.g. XimCompInitTables(), XimCompProcessSym()) which are not found anywhere, and the ordinary Compose implementation in xim doesn't use any of it. Signed-off-by:
Julien Cristau <jcristau@debian.org> Signed-off-by:
-
Alan Coopersmith authored
Signed-off-by:
-
Alan Coopersmith authored
Flagged by cppcheck 1.62: [lib/libX11/nx-X11/lib/X11/XKBGeom.c:479] -> [lib/libX11/nx-X11/lib/X11/XKBGeom.c:480]: (warning) Possible null pointer dereference: row - otherwise it is redundant to check it against null. Signed-off-by:
-
Alan Coopersmith authored
clear & selectAll are set to 0 already a few lines earlier, affectWhich is set to XkbMapNotifyMask a few lines later. None are used between the other assignments and the removed ones. Signed-off-by:
-
