From f3079e509c5cf60042ae2261499ee13b6b02498a Mon Sep 17 00:00:00 2001 From: Adam Jackson Date: Thu, 6 Feb 2020 13:45:35 -0500 Subject: [PATCH] xt: Work around a compiler issue with gcc 10 GRABEXT() is used to look up a pointer that sometimes lives just past the end of an XtServerGrabRec. Whether it's really there or not depends on XtServerGrabRec::hasExt. In a couple of places, we build those structs on the stack and pass them to other functions; such structs always have hasExt == 0, so GRABEXT would never get called in practice. However, there exists a bug in gcc 10 - more or less difficult to hit, depending on your compiler options and architecture - where it would not notice that the dereference after GRABEXT is dead code, at which point it looks like you're dereferencing one past the end of the array, which is illegal, and you you get: PassivGrab.c:292:35: error: array subscript 0 is outside array bounds of 'XtServerGrabRec[1]' {aka 'struct _XtServerGrabRec[1]'} [-Werror=array-bounds] As a completely stupid workaround, build those on-stack structs as arrays of two, so that the (dead) dereference looks like it's pointing into the dummy member of the array. This is almost certainly a compiler bug and I don't encourage merging this patch upstream, but if you need to build libXt with gcc 10 absolutely right this second, here it is. For details on the gcc issue, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582 --- src/PassivGrab.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/src/PassivGrab.c b/src/PassivGrab.c index bece0d9..b174d40 100644 --- a/src/PassivGrab.c +++ b/src/PassivGrab.c @@ -553,7 +553,7 @@ XtServerGrabPtr _XtCheckServerGrabsOnWidget ( _XtBoolean isKeyboard) { register XtServerGrabPtr grab; - XtServerGrabRec tempGrab; + XtServerGrabRec tempGrab[2]; XtServerGrabPtr *passiveListPtr; XtPerWidgetInput pwi; @@ -577,13 +577,13 @@ XtServerGrabPtr _XtCheckServerGrabsOnWidget ( /* Take only the lower thirteen bits as modifier state. The X Keyboard * Extension may be representing keyboard group state in two upper bits. */ - tempGrab.widget = widget; - tempGrab.keybut = (KeyCode) event->xkey.keycode; /* also xbutton.button */ - tempGrab.modifiers = event->xkey.state & 0x1FFF; /*also xbutton.state*/ - tempGrab.hasExt = False; + tempGrab[0].widget = widget; + tempGrab[0].keybut = (KeyCode) event->xkey.keycode; /* also xbutton.button */ + tempGrab[0].modifiers = event->xkey.state & 0x1FFF; /*also xbutton.state*/ + tempGrab[0].hasExt = False; for (grab = *passiveListPtr; grab; grab = grab->next) { - if (GrabMatchesSecond(&tempGrab, grab)) + if (GrabMatchesSecond(tempGrab, grab)) return (grab); } return (XtServerGrabPtr)NULL; @@ -775,17 +775,17 @@ void UngrabKeyOrButton ( Modifiers modifiers, Boolean isKeyboard) { - XtServerGrabRec tempGrab; + XtServerGrabRec tempGrab[2]; XtPerWidgetInput pwi; XtCheckSubclass(widget, coreWidgetClass, "in XtUngrabKey or XtUngrabButton"); /* Build a temporary grab list entry */ - tempGrab.widget = widget; - tempGrab.modifiers = (unsigned short) modifiers; - tempGrab.keybut = (KeyCode) keyOrButton; - tempGrab.hasExt = False; + tempGrab[0].widget = widget; + tempGrab[0].modifiers = (unsigned short) modifiers; + tempGrab[0].keybut = (KeyCode) keyOrButton; + tempGrab[0].hasExt = False; LOCK_PROCESS; pwi = _XtGetPerWidgetInput(widget, FALSE); @@ -817,7 +817,7 @@ void UngrabKeyOrButton ( /* Delete all entries which are encompassed by the specified grab. */ DeleteServerGrabFromList(isKeyboard ? &pwi->keyList : &pwi->ptrList, - &tempGrab); + tempGrab); } void XtGrabKey ( -- 2.23.0