From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46241) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agAg9-0003bP-BD for qemu-devel@nongnu.org; Wed, 16 Mar 2016 08:35:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1agAg4-0003MM-Cg for qemu-devel@nongnu.org; Wed, 16 Mar 2016 08:35:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33837) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agAg4-0003MH-7P for qemu-devel@nongnu.org; Wed, 16 Mar 2016 08:35:52 -0400 Message-ID: <1458131749.30910.13.camel@redhat.com> From: Gerd Hoffmann Date: Wed, 16 Mar 2016 13:35:49 +0100 In-Reply-To: <56E94BA9.5050309@weilnetz.de> References: <1458129049-12484-1-git-send-email-kraxel@redhat.com> <56E94BA9.5050309@weilnetz.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] input-linux: fix Coverity warning List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: qemu-devel@nongnu.org On Mi, 2016-03-16 at 13:03 +0100, Stefan Weil wrote: > Am 16.03.2016 um 12:50 schrieb Gerd Hoffmann: > > Signed-off-by: Gerd Hoffmann ---=20 > > ui/input-linux.c | 7 +++++++ 1 file changed, 7 insertions(+) > >=20 > > diff --git a/ui/input-linux.c b/ui/input-linux.c index > > 76a2abb..f884c00 100644 --- a/ui/input-linux.c +++ > > b/ui/input-linux.c @@ -257,6 +257,13 @@ static void > > input_linux_event_keyboard(void *opaque) */ continue; } + > > if (event.code >=3D KEY_CNT) { + /* + > > * Should not happen. But better safe than sorry, + > > * and we make Coverity happy too. + */ + > > continue; + } /* keep track of key state */ if > > (!il->keydown[event.code] && event.value) { il->keydown[event.code] > > =3D true; > >=20 >=20 > As it should not happen, I'd prefer this variant: >=20 > g_assert(event.code < KEY_CNT); Well, it is highly unlikely but not impossible. KEY_CNT changed from 0x200 to 0x300 in kernel 2.6.28. If (a) this happens again and (b) a new key > 0x300 is pressed and (c) we didn't sync the linux headers yet so qemu still has the old KEY_CNT value we could hit this. cheers, Gerd