From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 01EF78632A for ; Sun, 15 Feb 2026 17:49:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771177751; cv=none; b=BWxs4OVySD9cDdAw2EVBEV+XXE2dROxF90No61W+0A1BbBiDW12H8ICI8xaCCotkIVkj8pYawTUYdGSdmra0clGgZKiDwHQ7oi4ufTA2juzrv4Hq0C0r8blXNYZvjgpF9pLy7g9tLTk1cPIcTU3gCGf+ar+RPAgYbYCA6qbCQTA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771177751; c=relaxed/simple; bh=86Z7KQNlD4vPIi2HArTXAsnDnyGtVIXi+TFCu+3ZyUY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Q2ydOMtS+fx9UInQ2rD2HzOKMTR3IeW0j2j7j1GGRV29WWDT/Q024WqCPzGU/6adsRDBXMZURVfZpBl9Vam4QPCumefh6zHma6d3+1cpmvXze8dkOat6iDaND81wUxwLmUuzk76ZRG9+fMTFbOtMSr16S26epe7kP4O4Qiabdv0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=czxv+o87; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="czxv+o87" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D18AFC19423; Sun, 15 Feb 2026 17:49:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771177750; bh=86Z7KQNlD4vPIi2HArTXAsnDnyGtVIXi+TFCu+3ZyUY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=czxv+o87sRjfl9H0Hq2+YkkPSwSAqbuMpop+BaiPisDTwToxj9Ft87KpIvRKkjch8 HM8izNfMRsJ5lFaYBcxyLqQMXoRu1M0PaUamrqZj7nbn4xM+GMPuH4ONLgyeeN3kqR j/9hIhEj3TpjxYD5kF0RDNgDqdIv+PQwoW80TFbO8+I3b/nA5sJhRsQrOW89j/utaz sr7g2qBtOqGlcfCeXQaAtRVJ3o90jQZ/7+BVx9L9YI3TQk/b78wKsAzSyCMbE3qb4a rRtcjHbzRU69oZ3aby8iFUrNSgTStHFfiGnQExoqZiKbTgTP1l9ISCj58O0I29gqma 3aVc0E1MWNwYg== Date: Sun, 15 Feb 2026 18:49:06 +0100 From: Alexey Gladkov To: Areg Krdyan Cc: kbd@lists.linux.dev Subject: Re: [PATCH 4/4] libkeymap: add NULL check in lk_dump_ctable diacritical loop Message-ID: References: <20260214172813.1075064-1-areg.krdian@gmail.com> <20260214172813.1075064-4-areg.krdian@gmail.com> Precedence: bulk X-Mailing-List: kbd@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sun, Feb 15, 2026 at 11:04:05AM +0300, Areg Krdyan wrote: > Thanks for the reply! All the changes that I made were done by myself. > > I am currently undergoing an internship at Redsoft and my task is to > check the output of the static analyzer for kbd. I also wanted to fix > these static analyzer calls, some of them have already been fixed. Not > all of them are real errors, but they can help to detect the error > when changing the code. That's good, but the desire to satisfy the static analyzer should not be the only reason for making changes. Especially if the analyzer clearly does not fully understand the code. > Such checks are already in the project. Eg: > for (t = 0; t < MAX_NR_KEYMAPS; t++) { // libkeymap/kernel.c:24 > if (t > UCHAR_MAX) { > ERR(ctx, _("table %d must be less than %d"), t, UCHAR_MAX); > return -1; > } > ..... > } > With these constants, the error will never be triggered, since > MAX_NR_KEYMAPS = 256 and UCHAR_MAX = 255. But in the future, when > changing MAX_NR_KEYMAPS, it will be useful to have a check to detect > an error. The check for UCHAR_MAX here is not because of MAX_NR_KEYMAPS, but because KDGKBENT/KDSKBENT use struct kbentry, which defines kb_table as unsigned char. This cannot be changed because it is part of the Linux kernel API. > > Please let me know if patches of this kind are not needed. > Thanks again for your time. > -- Rgrds, legion