linux-kernel - Re: [PATCH v2 13/13] vt: refresh ucs_width_table.h and adjust code in ucs.c accordingly

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9ps0r788-qo06-4893-7753-4n3oo1238q23@syhkavp.arg>
Date: Wed, 16 Apr 2025 09:09:18 -0400 (EDT)
From: Nicolas Pitre <nico@...xnic.net>
To: Jiri Slaby <jirislaby@...nel.org>
cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
    linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 13/13] vt: refresh ucs_width_table.h and adjust code
 in ucs.c accordingly

On Wed, 16 Apr 2025, Jiri Slaby wrote:

> On 15. 04. 25, 21:18, Nicolas Pitre wrote:
> > From: Nicolas Pitre <npitre@...libre.com>
> > 
> > Width tables are now split into BMP (16-bit) and non-BMP (above 16-bit).
> > This reduces the corresponding text size by 20-25%.
> > 
> > Note: scripts/checkpatch.pl complains about "... exceeds 100 columns".
> >        Please ignore.
> ...
> > --- a/drivers/tty/vt/ucs.c
> > +++ b/drivers/tty/vt/ucs.c
> > @@ -5,17 +5,34 @@
> ...
> > -static int interval_cmp(const void *key, const void *element)
> > +static int interval16_cmp(const void *key, const void *element)
> > +{
> > +	u16 cp = *(u16 *)key;
> 
> You cast away const. Does the compiler not complain?

Nope.

> > +	const struct ucs_interval16 *entry = element;
> > +
> > +	if (cp < entry->first)
> > +		return -1;
> > +	if (cp > entry->last)
> > +		return 1;
> > +	return 0;
> > +}
> > +
> > +static int interval32_cmp(const void *key, const void *element)
> >   {
> >    u32 cp = *(u32 *)key;
> 
> Apparently not, given we do this for ages. I wonder why?

Because we're not creating another pointer that could be used for 
modifying the referenced memory.

> Anyway:
> 
> Reviewed-by: Jiri Slaby <jirislaby@...nel.org>
> 
> -- 
> js
> suse labs
> 
>