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: Compare font data for equality with font_data_is_equal() Date: Tue, 10 Mar 2026 12:19:44 +1000 Message-ID: In-Reply-To: <20260309141723.137364-11-tzimmermann@suse.de> References: <20260309141723.137364-1-tzimmermann@suse.de> <20260309141723.137364-11-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 The comment has a typo: "is constain" should be "it contains" and "also use= " should be "also uses". The function body: ```c + if (font_data_is_internal(lhs) !=3D font_data_is_internal(rhs)) + return false; ``` Good =E2=80=94 prevents matching internal fonts to user-space copies, which= would break refcounting. However, removing the width check from fbcon: ```c - tmp->vc_font.width =3D=3D w && ``` The commit message says "The test only compares data buffers. Their interpr= etation is up each console." But two fonts with different widths could have= identical byte sequences yet represent completely different glyphs (differ= ent pitch/scanline layout). The `font_data_is_equal` check relies on same-s= ize data implying same interpretation, but `size =3D height * pitch * charc= ount` =E2=80=94 two fonts could have `(height=3D16, width=3D8, pitch=3D1, c= harcount=3D256)` vs `(height=3D8, width=3D16, pitch=3D2, charcount=3D128)`,= both giving `size=3D4096` with potentially identical bytes but completely = different visual results. This seems like a correctness concern. --- Generated by Claude Code Patch Reviewer