From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: lib/fonts: Create font_data_t from struct console_font with font_data_import() Date: Tue, 10 Mar 2026 12:19:44 +1000 Message-ID: In-Reply-To: <20260309141723.137364-12-tzimmermann@suse.de> References: <20260309141723.137364-1-tzimmermann@suse.de> <20260309141723.137364-12-tzimmermann@suse.de> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review Good consolidation. Both fbcon and newport_con now share the same import lo= gic. In `font_data_import`, the `size` and `alloc_size` variables are declared a= s `int`: ```c int size, alloc_size; ``` But `check_mul_overflow` with unsigned inputs into a signed `int` output me= ans valid sizes above `INT_MAX` (which is ~2GB, so not a practical concern = for fonts) would be flagged as overflow. This is fine for font data but `un= signed int` or `size_t` would be more idiomatic. The change to newport_con removes the `vpitch !=3D 32` restriction: ```c - if ((w !=3D 8) || (h !=3D 16) || (vpitch !=3D 32) + if (w !=3D 8 || h !=3D 16 || (op->charcount !=3D 256 && op->charcount != =3D 512)) ``` The commit message says "Newport_con can now also handle input font data wi= th a vertical pitch other than 32 bytes" =E2=80=94 this is a behavioral cha= nge buried in a refactoring patch. It's likely correct since `font_data_imp= ort` handles arbitrary vpitch, but it changes what user-space font loads ne= wport_con will accept. --- Generated by Claude Code Patch Reviewer